| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Christoph Berg <myon(at)debian(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: compute_query_id and pg_stat_statements |
| Date: | 2021-05-13 03:06:52 |
| Message-ID: | 20210513030652.GB11075@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 13, 2021 at 09:57:00AM +0800, Julien Rouhaud wrote:
> 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
OK.
> 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?
Well, we don't have any other cases where the source of the change is
this indeterminate, so I don't really have a suggestion. I think this
does highlight another case where 'auto' just isn't a good fit for our
API.
> 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.
My point is that we are changing a setting from an extension, and if you
look in pg_setting, it will say "default"?
If the user already has to edit postgresql.conf to set
shared_preload_libraries, I still don't see why having them set
compute_query_id at the same time is a significant problem and a reason
to distort our API to do 'auto'.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro Horiguchi | 2021-05-13 03:11:12 | Re: compute_query_id and pg_stat_statements |
| Previous Message | Julien Rouhaud | 2021-05-13 02:59:24 | Re: compute_query_id and pg_stat_statements |