Re: track_planning causing performance regression

On Tue, Jun 29, 2021 at 10:09 AM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
>
> Checking back - here's the latest patch.
>
> diff --git a/doc/src/sgml/pgstatstatements.sgml b/doc/src/sgml/pgstatstatements.sgml
> index 930081c429..9e98472c5c 100644
> --- a/doc/src/sgml/pgstatstatements.sgml
> +++ b/doc/src/sgml/pgstatstatements.sgml
> @@ -696,8 +696,9 @@
> <varname>pg_stat_statements.track_planning</varname> controls whether
> planning operations and duration are tracked by the module.
> Enabling this parameter may incur a noticeable performance penalty,
> - especially when queries with the same queryid are executed on many
> - concurrent connections.
> + especially when queries with identical structure are executed by many
> + concurrent connections which compete to update a small number of
> + pg_stat_statements entries.
> The default value is <literal>off</literal>.
> Only superusers can change this setting.
> </para>

Is "identical structure" really accurate here? For instance a multi
tenant application could rely on the search_path and only use
unqualified relation name. So while they have queries with identical
structure, those will generate a large number of different query_id.