Re: [HACKERS] Planning counters in pg_stat_statements

From: Lukas Fittl <lukas(at)fittl(dot)com>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [HACKERS] Planning counters in pg_stat_statements
Date: 2018-03-30 19:04:41
Message-ID: CAP53PkwdPpFsMocHtP9u7hL4ZLdAs00m3bBGLWgdwhtz9sAASQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 23, 2018 at 3:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > Unfortunately I'm not going to have bandwidth to figure this out
> > during this commitfest due to other priorities so I'm going to call
> > this "returned with feedback".
>
> OK. There's still time to get it done in the March 'fest.
>

I've had an interesting incident earlier this week where seeing planning
time in pg_stat_statements would have been very helpful to determine the
root cause more quickly.

Essentially the situation was a statement that executed < 1ms but took more
than 250ms to plan, running often - once we found the statement (using
pg_stat_activity sampling) we were able to fix quickly by rewriting the
query and reduce system load from ~8 to ~1. Having this patch in
pg_stat_statements would have been critical to get the full picture of what
was going on earlier.

Thomas: I'm not as familiar with planner internals as you are, but happy to
try and contribute here. Would it be useful for me to try to adjust the
patch to Tom's proposal?

Best,
Lukas

--
Lukas Fittl

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2018-03-30 19:05:29 Re: [HACKERS] logical decoding of two-phase transactions
Previous Message Andres Freund 2018-03-30 18:50:37 Re: [HACKERS] logical decoding of two-phase transactions