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