On Mon, Apr 15, 2024 at 02:54:52PM +1200, David Rowley wrote:
> <filename>pg_stat_statements</filename> 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 <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.
> 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 <structfield>queryid</structfield>
> will be stable across major versions of <productname>PostgreSQL</productname>.
> + If in doubt, direct testing is recommended.
> </para>
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.
> <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.
This split is cleaner.
--
Michael