Re: compute_query_id and pg_stat_statements

On Wed, May 12, 2021 at 09:13:25PM -0400, Bruce Momjian wrote:
> On Thu, May 13, 2021 at 08:52:36AM +0800, Julien Rouhaud wrote:
> >
> > Well, as implemented you can get the value of compute_query_id, and if it's
> > still "auto" then it's not enabled as calling queryIdWanted() would turn it to
> > on. I agree that it's not ideal but you have a way to know. We could document
> > that auto means that it's set to auto and no one asked to automatically enabled
> > it.
>
> Wow, so the extension changes it?

Yes. It seemed better to go this way rather than having a secondary read-only
GUC for that.

> How do we record the "source" of that
> change? Do we have other GUCs that do that?

No, we don't. But I don't know what exactly you would like to have as a
source? What if you have for instance pg_stat_statements, pg_stat_kcache,
pg_store_plans and pg_wait_sampling installed? All those extensions need a
query_id (or at least benefit from it for pg_wait_sampling), is there any value
to give a full list of all the modules that would enable compute_query_id?

I'm assuming that anyone wanting to install any of those extensions (or any
similar one) is fully aware that they aggregate metrics based on at least a
query_id. If they don't, well they probably never read any documentation since
postgres 9.2 which introduced query normalization, and I doubt that they will
be interested in having access to the information anyway.