From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Fujii Masao <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 04:33:47 |
Message-ID: | CAOBaU_YgwO7zBXujxzpPXHy9omeUMS41YxtdkWYzhp1kdZ+sAg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
> > As the result, even if we take the DLL approach, still not need to
> > split out the query-id provider part. By the following config:
> >
> > > query_id_provider = 'pg_stat_statements'
> >
> > the core can obtain the entrypoint of, say, "_PG_calculate_query_id"
> > to call it. And it can be of another module.
> >
> > It seems like the only problem doing that is we don't have a means to
> > call per-process intializer for a preload libralies.
>
> So this is a crude PoC of that.
>
> 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
wrapper too? should the system complain or silently ignore when they all
try to install their provider function?
>
From | Date | Subject | |
---|---|---|---|
Next Message | Maciek Sakrejda | 2021-05-13 04:52:34 | Re: compute_query_id and pg_stat_statements |
Previous Message | Kyotaro Horiguchi | 2021-05-13 04:32:09 | Re: compute_query_id and pg_stat_statements |