Re: compute_query_id and pg_stat_statements

On 2021-May-16, Julien Rouhaud wrote:

> On Sat, May 15, 2021 at 10:00 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >
> > I am no longer the committer in charge of this feature, but I would like
> > to remind the group that beta1 will be wrapped on Monday, and it is hard
> > to change non-read-only GUCs after beta since the settings are embedded
> > in postgresql.conf. There is also a release notes item that probably
> > will need to be adjusted.
>
> It seems that everyone agrees on the definition of compute_query_id in
> Álvaro's v4 patch (module Justin's comments) so this could be
> committed before the beta1. If the safeguards for custom query_id or
> GUC misconfiguration have to be tweaked it shouldn't impact the GUC in
> any way.

Pushed after adding the fixes from Justin. Note I didn't include the
WARNING in pg_stat_statements when this is disabled; if anybody wants to
argue for that, let's add it separately.

I commented out the release notes para that is now wrong. What remains
is this:

Move query hash computation from pg_stat_statements to the core server (Julien Rouhaud)

We could perhaps add something like

Extension pg_stat_statements continues to work without requiring any
configuration changes.

but that seems a bit pointless. Or maybe

Extension pg_stat_statements automatically enables query identifier
computation if compute_query_id is set to auto. Third-party modules
to compute query identifiers can be installed and used if this is set
to off.

I wonder why the initial line says "query hash" instead of "query
identifier". Do we want to say "hash" everywhere? Why didn't we name
the GUC "compute_query_hash" in that case?

Anyway, let me remind you that it is pretty common to require initdb
during the beta period.

--
Álvaro Herrera Valdivia, Chile