Date: Wed, 12 May 2021 18:09:30 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: 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
Message-ID: <20210512100930.ex5cwkhng2gupgyn@nol>
References: <20210512024201.ak3ofofakn2ymhiv@nol>
 <20210512.143335.1053382893089496881.horikyota.ntt@gmail.com>
 <20210512060516.g2ebxgvbiglkgfv7@nol>
 <20210512.183724.859740020819002744.horikyota.ntt@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210512.183724.859740020819002744.horikyota.ntt@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20210512100930.ex5cwkhng2gupgyn%40nol>
Precedence: bulk

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?