Re: Any better plan for this query?..
От | Dimitri |
---|---|
Тема | Re: Any better plan for this query?.. |
Дата | |
Msg-id | 5482c80a0905190751w28142ed9nc5fb4a10e23d5fd7@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Any better plan for this query?.. (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-performance |
The response time is not progressive, it's simply jumping, it's likely since 16 sessions there is a sort of serialization happening somewhere.. As well on 16 sessions the throughput in TPS is near the same as on 8 (response time is only twice bigger for the moment), but on 32 it's dramatically dropping down.. Rgds, -Dimitri On 5/19/09, Simon Riggs <simon@2ndquadrant.com> wrote: > > On Tue, 2009-05-19 at 14:00 +0200, Dimitri wrote: > >> I may confirm the issue with hash join - it's repeating both with >> prepared and not prepared statements - it's curious because initially >> the response time is lowering near ~1ms (the lowest seen until now) >> and then once workload growing to 16 sessions it's jumping to 2.5ms, >> then with 32 sessions it's 18ms, etc.. > > Is it just bad all the time, or does it get worse over time? > > Do you get the same behaviour as 32 sessions if you run 16 sessions for > twice as long? > > -- > Simon Riggs www.2ndQuadrant.com > PostgreSQL Training, Services and Support > >
В списке pgsql-performance по дате отправления: