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