Re: compute_query_id and pg_stat_statements

Le sam. 24 avr. 2021 à 22:54, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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.

>