Horton

Re: RFC: extensible planner state

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-19T18:28:03Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Aug 19, 2025 at 1:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> * 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?

You'll presumably have to use GetMemoryChunkContext() for RelOptInfo,
so I don't see much downside from using it in one or even both of the
other cases too.

>> * 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?

Hm.  We don't have read support for these structs, so maybe it's fine.
It looks weird though.

			regards, tom lane

Commits

  1. Add extension_state member to PlannedStmt.

  2. Add planner_setup_hook and planner_shutdown_hook.

  3. Add ExplainState argument to pg_plan_query() and planner().

  4. Remove PlannerInfo's join_search_private method.

  5. Allow private state in certain planner data structures.

  6. Fix array allocation bugs in SetExplainExtensionState.

  7. Make it possible for loadable modules to add EXPLAIN options.