Re: compute_query_id and pg_stat_statements

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?