Horton

Re: RFC: extensible planner state

Melanie Plageman <melanieplageman@gmail.com>

View thread View on postgr.es
From: Melanie Plageman <melanieplageman@gmail.com>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-12T20:33:57Z
Lists: pgsql-hackers 
On Tue, Aug 26, 2025 at 4:58 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
>
> 1. Why is it necessary to maintain the GetExplainExtensionId and
> GetPlannerExtensionId routines? It seems that using a single
> extension_id (related to the order of the library inside the
> file_scanner) is more transparent and more straightforward if necessary.

But this wouldn't work for in-core use cases like GEQO, right? Also,
how would it work if there are multiple "extensions" in the same .so
file?

> 2. Why does the extensibility approach in 0001 differ from that in 0004?
> I can imagine it is all about limiting extensions, but anyway, a module
> has access to PlannerInfo, PlannerGlobal, etc. So, this machinery looks
> a little redundant, doesn't it?

What do you mean that the extensibility approach differs? Like that
the type of extension_state is different?

- Melanie

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.