Multiple Query IDs for a rewritten parse tree

On 5/1/2022 10:13, Tom Lane wrote:
> I feel like we need to get away from the idea that there is just
> one query hash, and somehow let different extensions attach
> differently-calculated hashes to a query. I don't have any immediate
> ideas about how to do that in a reasonably inexpensive way.

Now, queryId field represents an query class (depending on an jumbling
implementation). It is used by extensions as the way for simple tracking
a query from a parse tree creation point to the end of its life along
all hook calls, which an extension uses (remember about possible plan
caching).

I know at least two different cases of using queryId:
1) for monitoring purposes - pg_stat_statements is watching how often
queries of a class emerge in the database and collects a stat on each class.
2) adaptive purposes - some extensions influence a planner decision
during the optimization stage and want to learn on a performance shift
at the end of execution stage.

Different purposes may require different jumbling implementations. But
users can want to use such extensions at the same time. So we should
allow to attach many different query IDs to a query (maybe better to
call it as 'query label'?).

Thinking for a while I invented three different ways to implement it:
1. queryId will be a trivial 64-bit counter. So, each extension can
differ each query from any other, track it along all hooks, use an
jumbling code and store an queryId internally. Here only one big problem
I see - increasing overhead in the case of many consumers of queryId
feature.

2. Instead of simple queryId we can store a list of pairs (QueryId,
funcOid). An extension can register a callback for queryId generation
and the core will form a list of queryIds right after an query tree
rewriting. funcOid is needed to differ jumbling implementations. Here we
should invent an additional node type for an element of the list.

3. Instead of queryId we could add a multi-purpose 'private' list in the
Query struct. Any extension can add to this list additional object(s)
(with registered object type, of course). As an example, i can imagine a
kind of convention for queryIds in such case - store a String node with
value: '<extension name> - <Query ID>'.
This way we should implement a registered callback mechanism too.

I think, third way is the cheapest, flexible and simple for implementation.

Any thoughts, comments, criticism ?

--
regards,
Andrey Lepikhov
Postgres Professional