From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Jamie Koceniak <jkoceniak(at)mediamath(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Recursive query performance issue |
Date: | 2015-10-21 13:22:56 |
Message-ID: | CAHyXU0y_R6c9zvMYQ7t+Vu_jas9bhq-6iT85OUpuN9-JoKiXMg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Oct 20, 2015 at 12:34 PM, Jamie Koceniak
<jkoceniak(at)mediamath(dot)com> wrote:
> Version:
>
> -----------------------------------------------------------------------------------------------
>
> PostgreSQL 9.1.14 on x86_64-unknown-linux-gnu, compiled by gcc (Debian
> 4.7.2-5) 4.7.2, 64-bit
>
> Query Plan
>
> http://explain.depesz.com/s/4s37
>
> Normally, this query takes around 200-300 ms to execute.
>
> However when several queries are run concurrently, query performance drops
> to 30-60 seconds.
Please define 'several'. Essential information here is a capture of
'top' and possibly 'perf top'. Also if the problem is storage related
iostat can be very useful (or vmstat in a pinch)
FYI you can use pgbench with -f mode to measure concurrency
performance of any query.
The very first thing to rule out is a storage bottleneck via measured
iowait. Assuming that's the case, this problem is interesting if:
*) Scaling is much worse than it should be
*) You can confirm this on more modern postgres (interesting problems
are only interesting if they are unsolved)
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Jamie Koceniak | 2015-10-21 17:55:14 | Re: Recursive query performance issue |
Previous Message | Pavel Stehule | 2015-10-21 07:03:37 | Re: Recursive query performance issue |