Re: compute_query_id and pg_stat_statements

On Sat, May 15, 2021 at 02:21:59PM -0400, Álvaro Herrera wrote:
> 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.
>

OK, new text is:

<listitem>
<!--
Author: Bruce Momjian <bruce(at)momjian(dot)us>
2021-04-07 [5fd9dfa5f] Move pg_stat_statements query jumbling to core.
-->

<para>
Move query hash computation from pg_stat_statements to the core
server (Julien Rouhaud)
</para>

<para>
The new server variable compute_query_id's default of 'auto' will
automatically enable query id computation when this extension
is loaded.
</para>
</listitem>

I also added Alvaro as an author of the compute_query_id item.

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

It is queryid (no underscore) in pg_stat_statements, which was a whole
different discussion. ;-)

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

True.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

If only the physical world exists, free will is an illusion.