On Tue, 16 Apr 2024 at 12:10, Michael Paquier <mich...@paquier.xyz> wrote:
> Not sure that this is an improvement in clarity. There are a few
> bullet points that treat about the instability of the query ID, and
> your patch is now mixing the query ID being different for two
> mostly-identical queries on the same host with larger conditions like
> the environment involved. Perhaps it would be better to move the last
> sentence of the first <para> ("Furthermore, it is not safe..") with
> the part you are adding about replication in this paragraph.
Yeah, I think this is better. I think the attached is what you mean.
It makes sense to talk about the hashing variations closer to the
object identifier part.
David
diff --git a/doc/src/sgml/pgstatstatements.sgml
b/doc/src/sgml/pgstatstatements.sgml
index 44dd4db7ce..38c4ce3241 100644
--- a/doc/src/sgml/pgstatstatements.sgml
+++ b/doc/src/sgml/pgstatstatements.sgml
@@ -636,18 +636,21 @@
machine architecture and other facets of the platform.
Furthermore, it is not safe to assume that
<structfield>queryid</structfield>
will be stable across major versions of
<productname>PostgreSQL</productname>.
+ Two servers participating in replication based on physical WAL replay can
+ be expected to have identical <structfield>queryid</structfield> values for
+ the same query. However, logical replication schemes do not promise to
+ keep replicas identical in all relevant details, so
+ <structfield>queryid</structfield> will not be a useful identifier for
+ accumulating costs across a set of logical replicas.
+ If in doubt, direct testing is recommended.
</para>
<para>
- As a rule of thumb, <structfield>queryid</structfield> 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 <structfield>queryid</structfield> values for the same
query.
- However, logical replication schemes do not promise to keep replicas
- identical in all relevant details, so <structfield>queryid</structfield>
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 <structfield>queryid</structfield> values
+ are stable between minor version releases of
<productname>PostgreSQL</productname>,
+ 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.
</para>
<para>
