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
