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 CAOBaU_YL9WEpmZV8Q1E4J78A64C3HtE32LzZ+vrRPX5Y=8DPog@mail.gmail.com
Whole thread Raw
In response to compute_query_id and pg_stat_statements  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
Le sam. 24 avr. 2021 à 22:54, Fujii Masao <masao.fujii@oss.nttdata.com> a écrit :
For example, we already have one report about this issue, in [1].

this report was only a few days after the patch changing the behavior was committed, unless you've been following the original thread (which has been going on for 2 years), that's kind of expected. release notes for pg14 should highlight that change, so hopefully people upgrading will see it. I'll also try to write some blog article about it to add more warnings. 

Shouldn't we do something so that users can avoid such mis-configuration?

One idea is to change the default value of compute_query_id from false to true.
If enabling compute_query_id doesn't incur any performance penalty,
IMO this idea is very simple and enough.

it adds some noticeable overhead in oltp style workloads. I think that I did some benchmarks in the original thread, and we decided not to enable it by default 

Another idea is to change pg_stat_statements so that it emits an error
at the server startup (i.e., prevents the server from starting up)
if compute_query_id is not enabled. In this case, users can easily notice
the mis-configuration from the error message in the server log,
enable compute_query_id, and then restart the server.

that's also not an option, as one can now use pg_stat_statetements with a different queryid calculation. see for instance https://github.com/rjuju/pg_queryid for a proof a concept extension for that. I think it's clear that multiple people will want to use a different calculation as they have been asking for that for years. 

IMO the former is better if there is no such performance risk. Otherwise
we should adopt the latter approach. Or you have the better idea?

I'm not sure how to address that, as temporarily disabling queryId calculation should be allowed. maybe we could raise a warning once per backend if pgss sees a dml query without queryId? but it could end up creating more problems than it solves. 

for the record people have also raised bugs on the powa project because planning counters are not tracked by default, so compute_query_id will probably add a bit of traffic. 

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: compute_query_id and pg_stat_statements
Next
From: Bruce Momjian
Date:
Subject: Re: compute_query_id and pg_stat_statements