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@momjian.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@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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