Re: compute_query_id and pg_stat_statements

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: compute_query_id and pg_stat_statements
Дата
Msg-id 20210512.110836.2162399537656469720.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: compute_query_id and pg_stat_statements  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
At Tue, 11 May 2021 18:52:49 +0800, Julien Rouhaud <rjuju123@gmail.com> wrote in 
> On Tue, May 11, 2021 at 05:41:06PM +0800, Julien Rouhaud wrote:
> > On Tue, May 11, 2021 at 10:59:51AM +0200, Magnus Hagander wrote:
> > > 
> > > That doesn't fundamentally make it impossible, you just have to add it
> > > to the list of variables being copied over, wouldn't you? See
> > > save_backend_variables()
> > 
> > Yes, I agree, and that's what I meant by "explicitly handled".  The thing is
> > that I don't know if that's the best way to go, as it doesn't solve the "is it
> > actually enabled" and/or "which implementation is used".  At least the patch I
> > sent, although it's totally a hack, let you know if compute_query_id is enabled
> > or not.  I'm fine with implementing it that way, but only if there's a
> > consensus.
> 
> Actually, isn't that how e.g. wal_buffers = -1 is working?  The original value
> is lost and what you get is the computed value.  This is a bit different here
> as the value isn't always changed, and can be changed interactively but
> otherwise it's the same behavior.

If we look it in pg_settings, it shows the current value and the value
at boot-time.  So I'm fine with that behavior.

However, IMHO, I doubt the necessity of "on". Assuming that we require
any module that wants query-id to call queryIdWanted() at any time
after each process startup (or it could be inherited to children), I
think only "auto" and "off" are enough for the variable.  Thinking in
this line, the variable is a subset of a GUC variable to specify the
name of a query-id provider (as Andres suggested upthread), and I
think it would work better in future.

So for now I propose that we have a variable query_id_provider that
has only 'default' and 'none' as the domain.  We can later expand it
so that any other query-id provider modules can be loaded without
chaning the interface.

postgresql.conf
# query_id_provider = 'default'  # provider module for query-id. 'none' means
#                                # disabling query-id calculation.

If we want to have a direct way to know whether query-id is active or
not, it'd be good to have a read-only variable "query_id_active".

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
 



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Some other CLOBBER_CACHE_ALWAYS culprits
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Replication slot stats misgivings