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.ca...@moonset.ru Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION