Re: pg_stat_statements oddity with track = all - Mailing list pgsql-hackers

From Nikolay Samokhvalov
Subject Re: pg_stat_statements oddity with track = all
Date
Msg-id CANNMO++VRu2r17jqxBDFZF4++p+f4WE+VbvOPAQi_4BTwP4g=Q@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_statements oddity with track = all  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: pg_stat_statements oddity with track = all
List 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 by date:

Previous
From: Sergei Kornilov
Date:
Subject: Re: pg_stat_statements oddity with track = all
Next
From: Peter Eisentraut
Date:
Subject: macOS SIP, next try