Re: compute_query_id and pg_stat_statements

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: compute_query_id and pg_stat_statements
Дата
Msg-id 20210513030652.GB11075@momjian.us
обсуждение исходный текст
Ответ на Re: compute_query_id and pg_stat_statements  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: compute_query_id and pg_stat_statements  (Julien Rouhaud <rjuju123@gmail.com>)
Список 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@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: compute_query_id and pg_stat_statements
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: compute_query_id and pg_stat_statements