Re: pg_stat_statements oddity with track = all
| От | Nikolay Samokhvalov |
|---|---|
| Тема | Re: pg_stat_statements oddity with track = all |
| Дата | |
| Msg-id | CANNMO++VRu2r17jqxBDFZF4++p+f4WE+VbvOPAQi_4BTwP4g=Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_stat_statements oddity with track = all (Julien Rouhaud <rjuju123@gmail.com>) |
| Ответы |
Re: pg_stat_statements oddity with track = all
|
| Список | pgsql-hackers |
On Tue, Dec 1, 2020 at 10:32 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
On Tue, Dec 01, 2020 at 10:08:06PM -0800, Nikolay Samokhvalov wrote:
> 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.
If the same query is getting executed both at top level and as a nested
statement, two entries will then be created. That's probably unlikely for
things like RI trigger queries, but I don't know what to expect for client
application queries.
Right, but this is how things already work. The extra field you've proposed won't increase the number of records so it shouldn't affect how users choose pg_stat_statements.max.
В списке pgsql-hackers по дате отправления: