Re: RFC: extensible planner state

On Tue, Aug 19, 2025 at 1:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> This seems generally reasonable to me.

Cool.

> I wonder if we couldn't get rid of PlannerInfo.join_search_private
> in favor of expecting join search hooks to use this mechanism
> (thus, GEQO would become an in-core consumer of the mechanism).

Let me try that.

> * The initial allocations of the arrays need to take
> more care than this about which context the arrays go into,
> ie it had better be planner_cxt for PlannerInfo or PlannerGlobal,
> and the same context the RelOptInfo is in for RelOptInfo.
> Otherwise you risk a mess under GEQO.

It's easy to do this for PlannerInfo, but PlannerGlobal has no
planner_cxt member. GetMemoryChunkContext() could be used but I'm not
sure we want to spread reliance on that to more places. What's your
thought?

> * Surely, if extension_state etc is read_write_ignore, then
> extension_state_allocated etc had better be as well?  I don't
> understand the rationale for preserving one without the other.

I figured we can't print a void** but we can print an integer and the
user might want to see it. Wrong idea?

--
Robert Haas
EDB: http://www.enterprisedb.com