Re: Proposal - Allow extensions to set a Plan Identifier

On Sat, Mar 22, 2025 at 11:50:06PM +0100, Andrei Lepikhov wrote:
> planId actually looks less controversial than queryId or plan_node_id. At
> the same time, it is not free from the different logic that extensions may
> incorporate into this value: I can imagine, for example, the attempt of
> uniquely numbering plans related to the same queryId, plain hashing of the
> plan tree, hashing without constants, etc.

One plan ID should have one single query ID, but the opposite may be
not necessarily true: a query ID could be associated with multiple
plan patterns (aka multiple plan IDs). What this offers is that we
know about which plan one query is currently using in live, for a
given query ID.

> So, it seems that extensions may conflict with the same field. Are we sure
> that will happen if they are loaded in different orders in neighbouring
> backends?

Depends on what kind of computation once wants to do, and surely
without some coordination across the extensions you are using these
cannot be shared, but it's no different from the concept of a query
ID. The use cases I've seen where this field is useful is when
splitting code that uses the planner hook for several purposes across
more than one extension. Three of them which are independent, still
want to treat know about a plan ID:
- Set/get an existing node tree plan based on a specific ID.
- Hash calculation of a tree (like Lukas proposal).
- Statistics related to the plan tree used (aka custom cumulative
stats play here).

> I'm not very good at stat collector guts, but would it be possible to allow
> extensions to report their state in standard tuple format? In that case,
> doubts about queryId or planId may be resolved.

I am not exactly sure what you mean here. We are only going to have
one plan ID set for each query execution. Any stats plan data related
to a plan ID surely needs to be upper-bounded if you don't want to
bloat pgstats, with the query ID of the query string it relates to
stored in it and the plan ID used as hash key, but it does not change
that we're only going to always have one single plan ID in a
PlannedStmt or in a backend entry doing a query execution, like a
query ID.
--
Michael