Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 6da67a0

Browse files
committed
doc: Mention de-normalization of deallocated entries in pg_stat_statements
The current implementation of query normalization in pg_stat_statements is optimistic. If an entry is deallocated between the post-analyze hook and the planner and/or execution hook, it can be possible to find query strings with literal constant values (like "SELECT 1, 2") rather than their normalized flavor (like "SELECT $1, $2"). This commit adds in the documentation a paragraph about this limitation, and that this risk can be reduced by increasing pg_stat_statements.max, particularly if pg_stat_statements_info reports a high number of deallocations. Author: Sami Imseih Discussion: https://postgr.es/m/9CFF3512-355B-4676-8CCC-6CF622F4DC1A@amazon.com
1 parent 6a88a05 commit 6da67a0

File tree

1 file changed

+10
-0
lines changed

1 file changed

+10
-0
lines changed

doc/src/sgml/pgstatstatements.sgml

+10
Original file line numberDiff line numberDiff line change
@@ -516,6 +516,16 @@
516516
<structname>pg_stat_statements</structname> entry.
517517
</para>
518518

519+
<para>
520+
Queries on which normalization can be applied may be observed with constant
521+
values in <structname>pg_stat_statements</structname>, especially when there
522+
is a high rate of entry deallocations. To reduce the likelihood of this
523+
happening, consider increasing <varname>pg_stat_statements.max</varname>.
524+
The <structname>pg_stat_statements_info</structname> view, discussed below
525+
in <xref linkend="pgstatstatements-pg-stat-statements-info"/>,
526+
provides statistics about entry deallocations.
527+
</para>
528+
519529
<para>
520530
In some cases, queries with visibly different texts might get merged into a
521531
single <structname>pg_stat_statements</structname> entry. Normally this will happen

0 commit comments

Comments
 (0)