From: Julien Rouhaud <rjuju123@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: magnus@hagander.net
Cc: masao.fujii@oss.nttdata.com
Cc: michael@paquier.xyz
Cc: andres@anarazel.de
Cc: tgl@sss.pgh.pa.us
Cc: alvherre@alvh.no-ip.org
Cc: sfrost@snowman.net
Cc: bruce@momjian.us
Cc: myon@debian.org
Cc: peter.eisentraut@enterprisedb.com
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: compute_query_id and pg_stat_statements
Date: Wed, 12 May 2021 18:09:30 +0800
Message-ID: <20210512100930.ex5cwkhng2gupgyn@nol> (raw)
In-Reply-To: <20210512.183724.859740020819002744.horikyota.ntt@gmail.com>
References: <20210512024201.ak3ofofakn2ymhiv@nol>
<20210512.143335.1053382893089496881.horikyota.ntt@gmail.com>
<20210512060516.g2ebxgvbiglkgfv7@nol>
<20210512.183724.859740020819002744.horikyota.ntt@gmail.com>
On Wed, May 12, 2021 at 06:37:24PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 12 May 2021 14:05:16 +0800, Julien Rouhaud <rjuju123@gmail.com> wrote in
> >
> > And if I'm not mistaken, pg_store_plans also wants a different queryid
> > implementation, but has to handle a secondary queryid on top of it
> > (https://github.com/ossc-db/pg_store_plans/blob/master/pg_store_plans.c#L843-L855).
>
> Yeah, the extension intended to be used joining with the
> pg_stat_statements view. And the reason for the second query-id dates
> back to the era when query id was not available in the
> pg_stat_statements view. Now it is mere a fall-back query id when
> pg_stat_statments is not active. Now that the in-core query-id is
> available, I think there's no reason to keep that implement.
>
> > So here again what the extension want is to get rid of pg_stat_statements (and
> > now core) queryid implementation.
>
> So the extension might be a good reason for the discussion^^;
Indeed. So IIUC, what pg_store_plans wants is:
- to use its own query_id implementation
- to be able to be joined to pg_stat_statements
Is that correct?
If yes, it seems that starting with pg14, it can be easily achieved by:
- documenting to disable compute_query_id
- eventually error out at execution time if it's enabled
- don't call queryIdWanted()
- expose its query_id
It will then work just fine, and will be more efficient compared to what is
done today as only one queryid will be calculated.
Did I miss something?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: rjuju123@gmail.com, horikyota.ntt@gmail.com, magnus@hagander.net, masao.fujii@oss.nttdata.com, michael@paquier.xyz, andres@anarazel.de, tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, sfrost@snowman.net, bruce@momjian.us, myon@debian.org, peter.eisentraut@enterprisedb.com, pgsql-hackers@lists.postgresql.org
Subject: Re: compute_query_id and pg_stat_statements
In-Reply-To: <20210512100930.ex5cwkhng2gupgyn@nol>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox