diff --git a/doc/src/sgml/pgstatstatements.sgml b/doc/src/sgml/pgstatstatements.sgml
index 4d7a6e68ea..d4f09fc2a3 100644
--- a/doc/src/sgml/pgstatstatements.sgml
+++ b/doc/src/sgml/pgstatstatements.sgml
@@ -270,7 +270,7 @@
- Consumers of pg_stat_statements> may wish to use
+ Consumers of pg_stat_statements> may wish to use
queryid> (perhaps in combination with
dbid> and userid>) as a more stable
and reliable identifier for each entry than its query text.
@@ -280,7 +280,7 @@
post-parse-analysis tree, its value is a function of, among other
things, the internal object identifiers appearing in this representation.
This has some counterintuitive implications. For example,
- pg_stat_statements> will consider two apparently-identical
+ pg_stat_statements> will consider two apparently-identical
queries to be distinct, if they reference a table that was dropped
and recreated between the executions of the two queries.
The hashing process is also sensitive to differences in
@@ -300,6 +300,20 @@
not be a useful identifier for accumulating costs across a set of logical
replicas. If in doubt, direct testing is recommended.
+
+
+ The representative query texts are kept in an external disk file, and do
+ not consume shared memory. Therefore, even very lengthy query texts can
+ be stored successfully. However, if many long query texts are
+ accumulated, the external file might grow unmanageably large. As a
+ recovery method if that happens, pg_stat_statements> may
+ choose to discard the query texts, whereupon all existing entries in
+ the pg_stat_statements> view will show
+ null query> fields, though the statistics associated with
+ each queryid> are preserved. If this happens, consider
+ reducing pg_stat_statements.max to prevent
+ recurrences.
+