On Wed, May 12, 2021 at 06:37:24PM +0900, Kyotaro Horiguchi wrote: > At Wed, 12 May 2021 14:05:16 +0800, Julien Rouhaud <rjuju...@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?
