| From: | Dimitri <dimitrik(dot)fr(at)gmail(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Any better plan for this query?.. |
| Date: | 2009-05-19 14:51:55 |
| Message-ID: | 5482c80a0905190751w28142ed9nc5fb4a10e23d5fd7@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)2ndquadrant(dot)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
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri | 2009-05-19 15:53:51 | Re: Any better plan for this query?.. |
| Previous Message | Robert Haas | 2009-05-19 14:00:36 | Re: Any better plan for this query?.. |