Re: Stability of queryid in minor versions

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