From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | rjuju123(at)gmail(dot)com |
Cc: | magnus(at)hagander(dot)net, masao(dot)fujii(at)oss(dot)nttdata(dot)com, michael(at)paquier(dot)xyz, andres(at)anarazel(dot)de, tgl(at)sss(dot)pgh(dot)pa(dot)us, alvherre(at)alvh(dot)no-ip(dot)org, sfrost(at)snowman(dot)net, bruce(at)momjian(dot)us, myon(at)debian(dot)org, peter(dot)eisentraut(at)enterprisedb(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: compute_query_id and pg_stat_statements |
Date: | 2021-05-13 07:15:30 |
Message-ID: | 20210513.161530.167271680283992706.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Thu, 13 May 2021 12:33:47 +0800, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote in
> Le jeu. 13 mai 2021 à 12:26, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> a
> écrit :
>
> > At Thu, 13 May 2021 12:11:12 +0900 (JST), Kyotaro Horiguchi <
> > horikyota(dot)ntt(at)gmail(dot)com> wrote in
> > pg_stat_statemnts defines its own query-id provider function in
> > pg_stat_statements which calls in-core DefaultJumbeQuery (end emits a
> > log line).
> >
> > If server started with query_id_provider='auto' and pg_stat_statements
> > is not loaded, pg_stat_activity.query_id is null.
> >
> > If query_id_provider='auto' and pg_stat_statements is loaded,
> > pg_stat_activity.query_id is filled in with a query id.
> >
> > If query_id_provider='default' or 'pg_stat_statements' and
> > pg_stat_statements is not loaded, pg_stat_activity.query_id is filled
> > in with a query id.
> >
> > If query_id_provider='none' and pg_stat_statements is loaded, it
> > complains as "query id provider is not available" and refuss to start.
> >
> > If showing the variable, it shows the real provider name instead of
> > the setting in postgresql.conf.
> >
>
> what if you want to have some other extensions like pg_stat_kcache or
> pg_store_plans that need a query_id but don't really care if
> pg_stat_statements is enabled or not? should they all declare their own
Thanks for looking it.
The addtional provider function in pg_stat_statements is just an
example to show what if it needs its own query-id provider, which is
useless in reality. In reality pg_stat_statements just calls
"queryIdWanted("default", true)" to use any query-id provider and use
the in-core one as the fallback implement, and no need to define its
own one.
Any extension can use the in-core provider and accepting any other
ones by calling queryIdWanted("default", true) then get what they want
regardless of existence of pg_stat_statements.
> wrapper too? should the system complain or silently ignore when they all
> try to install their provider function?
Of course if two extensions require diffrent query-id providers, they
just cannot coexist (that is, server refuses to start). It is quite
sane behavior in the standpoint of safety. I think almost all
query-id users don't insist on a specific implmentation. (So the
second parameter to queryIdWanted() could be omtted and assumed to be
true.)
reagrds.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-05-13 07:27:47 | Re: Teaching users how they can get the most out of HOT in Postgres 14 |
Previous Message | Dilip Kumar | 2021-05-13 07:06:28 | Re: [Patch] ALTER SYSTEM READ ONLY |