On 1/3/25 03:46, Lukas Fittl wrote:
> My overall perspective is that (1) is best done in-core to keep overhead
> low, whilst (2) could be done outside of core (or merged with a future
> pg_stat_statements) and is included here mainly for illustration purposes.
Thank you for the patch and your attention to this issue!
I am pleased with the export of the jumbling functions and their
generalisation.
I may not be close to the task monitoring area, but I utilise queryId
and other tools to differ plan nodes inside extensions. Initially, like
queryId serves as a class identifier for queries, plan_id identifies a
class of nodes, not a single node. In the implementation provided here,
nodes with the same hash can represent different subtrees. For example,
JOIN(A, JOIN(B,C)) and JOIN(JOIN(B,C),A) may have the same ID.
Moreover, I wonder if this version of plan_id reacts to the join level
change. It appears that only a change of the join clause alters the
plan_id hash value, which means you would end up with a single hash for
very different plan nodes. Is that acceptable? To address this, we
should consider the hashes of the left and right subtrees and the hashes
of each subplan (especially in the case of Append).
Overall, similar to discussions on queryId, various extensions may want
different logic for generating plan_id (more or less unique guarantees,
for example). Hence, it would be beneficial to separate this logic and
allow extensions to provide different plan_ids. IMO, What we need is a
'List *ext' field in each of the Plan, Path, PlanStmt, and Query
structures. Such 'ext' field may contain different stuff that extensions
want to push without interference between them - specific plan_id as an
example.
Additionally, we could bridge the gap between the cloud of paths and the
plan by adding a hook at the end of the create_plan_recurse routine.
This may facilitate the transfer of information regarding optimiser
decisions that could be influenced by an extension into the plan.
--
regards, Andrei Lepikhov
