Re: Multiple Query IDs for a rewritten parse tree

On 29/1/2022 12:51, Julien Rouhaud wrote:
>>> 4. We should reserve position of default in-core generator
>>
>>  From the discussion above I was under the impression that the core
>> generator should be distinguished by a predefined kind.
> 
> I don't really like this approach.  IIUC, this patch as-is is meant to break
> pg_stat_statements extensibility.  If kind == 0 is reserved for in-core queryid
> then you can't use pg_stat_statement with a different queryid generator
> anymore.

Yes, it is one more problem. Maybe if we want to make it extensible, we 
could think about hooks in the pg_stat_statements too?

> The patch also reserves kind == -1 for pg_stat_statements internal purpose, and
> I'm not really sure why that's needed.
My idea - tags with positive numbers are reserved for generation 
results, that is performance-critical.
As I see during the implementation, pg_stat_statements makes additional 
changes on queryId (no matter which ones). Because our purpose is to 
avoid interference in this place, I invented negative values, where 
extensions can store their queryIds, based on any generator or not. 
Maybe it is redundant - main idea here was to highlight the issue.
> 
> I'm also unsure of how are extensions supposed to cooperate in general, as
> I feel that queryids should be implemented for some "intent" (like monitoring,
> planning optimization...).  That being said I'm not sure if e.g. AQO heuristics
> are too specific for its need or if it could be shared with other extension
> that might be dealing with similar concerns.
I think, it depends on a specific purpose of an extension.

-- 
regards,
Andrey Lepikhov
Postgres Professional