Re: compute_query_id and pg_stat_statements - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: compute_query_id and pg_stat_statements
Date
Msg-id 20210514035733.hkcf3alnbyofmplu@nol
Whole thread Raw
In response to Re: compute_query_id and pg_stat_statements  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: compute_query_id and pg_stat_statements
List pgsql-hackers
On Fri, May 14, 2021 at 12:20:00PM +0900, Fujii Masao wrote:
> 
> 
> On 2021/05/14 9:04, Alvaro Herrera wrote:
> > Here's a first attempt at what was suggested.  If you say "auto" it
> > remains auto in SHOW, but it gets enabled if a module asks for it.
> > 
> > Not final yet, but I thought I'd throw it out for early commentary ...
> 
> Many thanks! The patch basically looks good to me.
> 
> +void
> +EnableQueryId(void)
> +{
> +    if (compute_query_id == COMPUTE_QUERY_ID_AUTO)
> +        auto_query_id_enabled = true;
> 
> Shouldn't EnableQueryId() enable auto_query_id_enabled whatever compute_query_id is?
> Otherwise, for example, the following scenario can happen and it's a bit strange.
> 
> 1. The server starts up with shared_preload_libraries=pg_stat_statements and compute_query_id=on
> 2. compute_query_id is set to auto and the configuration file is reloaded
> Then, even though compute_query_id is auto and pg_stat_statements is loaded,
> query ids are not computed and no queries are tracked by pg_stat_statements.

+1.  Note that if you switch from compute_query_id = off + custom
query_id + pg_stat_statements to compute_query_id = auto then thing will
immediately break (as we instruct third-party plugins authors to error out in
that case), which is way better than breaking at the next random service
restart.



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: compute_query_id and pg_stat_statements
Next
From: David Rowley
Date:
Subject: Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?