Re: track_planning causing performance regression

On Tue, Jun 29, 2021 at 10:09 AM Justin Pryzby <pryzby@telsasoft.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.