Re: pg_stat_statements oddity with track = all

Поиск
Список
Период
Сортировка
От Nikolay Samokhvalov
Тема Re: pg_stat_statements oddity with track = all
Дата
Msg-id CANNMO+KrVxMTrzSJLkrkENQX7utVYo1SEyaW54N+Y-Zjew=wbQ@mail.gmail.com
обсуждение исходный текст
Ответ на pg_stat_statements oddity with track = all  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: pg_stat_statements oddity with track = all  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
On Tue, Dec 1, 2020 at 8:05 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
Hi,

Someone raised an interested point recently on pg_stat_kcache extension for
handling nested statements, which also applies to pg_stat_statements.
... 
The only idea I have for that is to add a new field to entry key, for instance
is_toplevel.

This particular problem often bothered me when dealing with pg_stat_statements contents operating under "track = all" (especially when performing the aggregated analysis, like you showed).

I think the idea of having a flag to distinguish the top-level entries is great.
 
The immediate cons is obviously that it could amplify quite a lot
the number of entries tracked, so people may need to increase
pg_stat_statements.max to avoid slowdown if that makes them reach frequent
entry eviction.

If all top-level records in pg_stat_statements have "true" in the new column (is_toplevel), how would this lead to the need to increase pg_stat_statements.max? The number of records would remain the same, as before extending pg_stat_statements.

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: unescape_text function
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: pg_stat_statements oddity with track = all