Re: allowing extensions to control planner behavior

On Wed, Aug 28, 2024 at 07:25:59PM -0400, Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> > Beyond awkwardness, one case where it matters is the interaction
> > between an extension that provides hints and an extension that offers a
> > CustomScan. How is the hints extension supposed to disable a path it
> > doesn't know about?

pg_hint_plan documents its hints here:
https://pg-hint-plan.readthedocs.io/en/master/hint_list.html#hint-list

Hmm. I think that we should be careful to check that this works
correctly with pg_hint_plan, at least. The module goes through a lot
of tweaks and is a can of worms in terms of plan adjustments because
we can only rely on the planner hook to do the whole work. This leads
to a lot of frustration for users because each feature somebody asks
for leads to just more tweaks to apply on the paths.

The bullet list sent here sounds pretty good to me:
https://www.postgresql.org/message-id/3131957.1724789735@sss.pgh.pa.us

> This does not seem remarkably problematic to me, given Robert's
> proposal of a bitmask of allowed plan types per RelOptInfo.
> You just do something like
>
> rel->allowed_plan_types = DESIRED_PLAN_TYPE;
>
> The names of the bits you aren't setting are irrelevant to you.

For the types of scans to use, that would be OK. The module has a
feature where one can also have a regex to match for an index, and
the module is very funky with inheritance and partitioned tables.

How does that help if using a Leading hint to force a join order?
That's something people like a lot. But perhaps that's just the part
of upthread where we'd need a extra hook? I am not completely sure to
get the portion of the proposal for that. add_paths_to_joinrel() has
been mentioned, and there is set_join_pathlist_hook already there.
--
Michael