diff --git a/doc/src/sgml/pgstatstatements.sgml b/doc/src/sgml/pgstatstatements.sgml index 44dd4db7ce..302421306e 100644 --- a/doc/src/sgml/pgstatstatements.sgml +++ b/doc/src/sgml/pgstatstatements.sgml @@ -632,22 +632,25 @@ 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. + Two servers participating in replication based on physical WAL replay can + be expected to have identical queryid values for + the same query. However, logical replication schemes do not promise to + keep replicas identical in all relevant details, so + queryid will not be a useful identifier for + accumulating costs across a set of logical replicas. The hashing process is also sensitive to differences in machine architecture and other facets of the platform. Furthermore, it is not safe to assume that queryid will be stable across major versions of PostgreSQL. + If in doubt, direct testing is recommended. - As a rule of thumb, queryid values can be assumed to be - stable and comparable only so long as the underlying server version and - catalog metadata details stay exactly the same. Two servers - participating in replication based on physical WAL replay can be expected - to have identical queryid values for the same query. - However, logical replication schemes do not promise to keep replicas - identical in all relevant details, so queryid will - not be a useful identifier for accumulating costs across a set of logical - replicas. If in doubt, direct testing is recommended. + Generally, it can be assumed that queryid values + are stable between minor version releases of PostgreSQL, + providing that instances are running on the same machine architecture and + the catalog metadata details match. Compatibility will only be broken + between minor versions as a last resort.