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
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 |