Re: [HACKERS] Planning counters in pg_stat_statements

Поиск
Список
Период
Сортировка
От Lukas Fittl
Тема Re: [HACKERS] Planning counters in pg_stat_statements
Дата
Msg-id CAP53PkwdPpFsMocHtP9u7hL4ZLdAs00m3bBGLWgdwhtz9sAASQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Planning counters in pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Planning counters in pg_stat_statements
Список pgsql-hackers
On Tue, Jan 23, 2018 at 3:31 PM, Tom Lane <tgl@sss.pgh.pa.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] logical decoding of two-phase transactions
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: [HACKERS] logical decoding of two-phase transactions