Re: RFC: extensible planner state

On 19/8/2025 18:47, Robert Haas wrote:
> polishing. If people do not like this design, then I would like to
> know what alternative they would prefer.Thanks for these efforts!

Generally, such an interface seems good for the extension's purposes. It 
is OK in this specific context because all these structures are created 
during the planning process. Going further into the plan, which is more 
stable and reusable, you would need to think about read/write rules.

I utilise PlannerGlobal extensibility to notify my extension when a 
transformation or optimisation occurs, enabling it to initiate 
replanning from the top level with alternative settings if necessary. 
RelOptInfo extensibility serves multiple purposes, but its most notable 
feature is the inclusion of a node signature that enables the 
identification of a specific RelOptInfo instance during re-optimisation 
of all or only a part of the query. I haven't used PlannerInfo 
extensibility yet, but I think it makes sense - if an extension performs 
a complicated planning job that spans multiple planning stages, it makes 
sense to store intermediate data in this 'cache'.

The weak points of this approach are:
1. Needs a new core routine for each node to be extended.
2. Doesn't propose copy/read/write node machinery.
3. Allocates more memory than needed. I frequently see installations 
with 5-10 modules installed. If the 9th extension employs the RelOptInfo 
extensibility, it would be unfortunate to see another eight elements 
allocated unnecessarily. What if we ever consider extending the Path node?

I have been using a slightly different approach [1] for years, which 
involves adding a List at the end of each structure. Any extension, by 
convention, may add elements as an ExtensibleNode. Such an approach 
saves memory, resolves read/write/copy node issues and allows an 
extension to correctly identify its data in parallel workers and across 
backends (see [2] for the reasoning). This approach appears more general 
(though less restrictive) and can be applied to extend any node in the 
same way, which offers a clear benefit, because tracking query planning 
decisions often requires extensibility in Query, RelOptInfo, and 
PlannedStmt as well.

Although I prefer the ExtensibleNode / extension list approach, I will 
be OK with your method as well, especially if you add extensibility to 
the PlannedStmt node too.

[1] https://commitfest.postgresql.org/patch/5965/
[2] https://www.postgresql.org/message-id/aKQIeXKMifXqV58R@jrouhaud

-- 
regards, Andrei Lepikhov