Re: Stability of queryid in minor versions

On Mon, Apr 15, 2024 at 02:54:52PM +1200, David Rowley wrote:
>     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.
>    

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  ("Furthermore, it is not safe..") with
the part you are adding about replication in this paragraph.

>    
> -   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.

This split is cleaner.
--
Michael