Re: track_planning causing performance regression - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: track_planning causing performance regression
Date
Msg-id CAOBaU_bg0OcRUykMP=_XY7tsBfjtq1NW=JeO5=p=QRg8hXAT1A@mail.gmail.com
Whole thread Raw
In response to Re: track_planning causing performance regression  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: PG 14 release notes, first draft
Next
From: Amit Kapila
Date:
Subject: Re: missing GRANT on pg_subscription columns