Re: compute_query_id and pg_stat_statements

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: compute_query_id and pg_stat_statements
Дата
Msg-id 20210513031613.j47baglf6xl3mgbs@nol
обсуждение исходный текст
Ответ на Re: compute_query_id and pg_stat_statements  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: compute_query_id and pg_stat_statements  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Wed, May 12, 2021 at 11:06:52PM -0400, Bruce Momjian wrote:
> On Thu, May 13, 2021 at 09:57:00AM +0800, Julien Rouhaud wrote:
> 
> > 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.

It may depends on your next question

> > 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"?

No, it will say "on".  What the patch I sent implements is:

- compute_query_id = on means it was either explicitly set to on, or
  automatically set to on if it was allowed to (so initially set to auto).  It
  means you know whether core query_id calculation is enabled or not, you can
  know looking at the reset value it it was changed by an extension, you just
  don't know which one(s).

- compute_query_id = auto means that it can be set to on, it just wasn't yet,
  so it's off, and may change if you have an extension that can be dynamically
  loaded and request for core query_id calculation to be enabled

- compute_query_id = off means it's off

> 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'.

Looking at the arguments until now my understanding is that it's because "no
one will read the doc anyway".



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

Предыдущее
От: Japin Li
Дата:
Сообщение: Re: alter subscription drop publication fixes
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: PG 14 release notes, first draft