Re: Doc update for pg_stat_statements normalization

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Doc update for pg_stat_statements normalization
Date: 2023-02-28 04:56:25
Message-ID: Y/2JecAVDcD/iIKQ@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 24, 2023 at 08:54:00PM +0000, Imseih (AWS), Sami wrote:
> I think the only thing to do here is to call this out in docs with a suggestion to increase
> pg_stat_statements.max to reduce the likelihood. I also attached the suggested
> doc enhancement as well.

+ <para>
+ A query text may be observed with constants in
+ <structname>pg_stat_statements</structname>, especially when there is a high
+ rate of entry deallocations. To reduce the likelihood of this occuring, consider
+ increasing <varname>pg_stat_statements.max</varname>.
+ The <structname>pg_stat_statements_info</structname> view provides entry
+ deallocation statistics.
+ </para>

I am OK with an addition to the documentation to warn that one may
have to increase the maximum number of entries that can be stored if
seeing a non-normalized entry that should have been normalized.

Shouldn't this text make it clear that this concerns only query
strings that can be normalized? Utility queries can have constants,
for one (well, not for long for most of them with the work I have been
doing lately, but there will still be some exceptions like CREATE
VIEW or utilities with A_Const nodes).
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-02-28 05:01:04 Re: Allow tests to pass in OpenSSL FIPS mode
Previous Message Julien Rouhaud 2023-02-28 04:48:27 Re: pg_upgrade and logical replication