Re: compute_query_id and pg_stat_statements - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: compute_query_id and pg_stat_statements
Date
Msg-id YJoeXcrwe1EDmqKT@paquier.xyz
Whole thread Raw
In response to Re: compute_query_id and pg_stat_statements  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: compute_query_id and pg_stat_statements  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Re: compute_query_id and pg_stat_statements  (Julien Rouhaud <rjuju123@gmail.com>)
Re: compute_query_id and pg_stat_statements  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Tue, Apr 27, 2021 at 02:25:04PM +0800, Julien Rouhaud wrote:
> On Mon, Apr 26, 2021 at 11:37:45AM -0700, Andres Freund wrote:
>> On 2021-04-26 14:21:00 -0400, Tom Lane wrote:
>>> That's sounding like a pretty sane design, actually.  Not sure about
>>> the shared-library-name-with-fixed-function-name detail, but certainly
>>> it seems to be useful to separate "I need a query-id" from the details
>>> of the ID calculation.
>>>
>>> Rather than a GUC per se for the ID provider, maybe we could have a
>>> function hook that defaults to pointing at the in-core computation,
>>> and then a module wanting to override that just gets into the hook.
>>
>> I have a preference to determining the provider via GUC instead of a
>> hook because it is both easier to introspect and easier to configure.

So, this thread has died two weeks ago, and it is still an open item.
Could it be possible to move to a resolution by beta1?  The consensus
I can get from the thread is that we should have a tri-value state to
track an extra "auto" for the query ID computation, as proposed by
Alvaro here:
https://www.postgresql.org/message-id/20210426174331.GA19401@alvherre.pgsql

Unfortunately, nothing has happened to be able to do something like
that.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: [Patch] ALTER SYSTEM READ ONLY
Next
From: Fujii Masao
Date:
Subject: Re: compute_query_id and pg_stat_statements