compute_query_id and pg_stat_statements - Mailing list pgsql-hackers

From Fujii Masao
Subject compute_query_id and pg_stat_statements
Date
Msg-id 35457b09-36f8-add3-1d07-6034fa585ca8@oss.nttdata.com
Whole thread Raw
Responses Re: compute_query_id and pg_stat_statements
Re: compute_query_id and pg_stat_statements
List pgsql-hackers
When compute_query_id is not enabled (this is the default setting),
pg_stat_statements doesn't track any statements. This means that
we will see no entries in pg_stat_statements by default. I'm afraid that
users may easily forget to enable compute_query_id
when using pg_stat_statements (because this setting was not necessary
in v13 or before), and finally may have noticed the mis-configuration
and failure of statements tracking after many queries were executed.
For example, we already have one report about this issue, in [1].

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.

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.

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?

Thought?

[1]
https://postgr.es/m/1953aec168224b95b0c962a622bef0794da6ff40.camel@moonset.ru

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: multi-install PostgresNode fails with older postgres versions
Next
From: Julien Rouhaud
Date:
Subject: Re: compute_query_id and pg_stat_statements