Subject: Re: allowing extensions to control planner behavior

From: Jeff Davis <[email-masked]>
Date: Wed, 28 Aug 2024 16:15:51 -0700

On Wed, 2024-08-28 at 16:35 -0400, Robert Haas wrote:
> On Wed, Aug 28, 2024 at 4:29 PM Jeff Davis <[email-masked]> wrote:
> > Preserving a path for the right amount of time seems like the
> > primary
> > challenge for most of the use cases you raised (removing paths is
> > easier than resurrecting one that was pruned too early). If we try
> > to
> > keep a path around, that implies that we need to keep parent paths
> > around too, which leads to an explosion if we aren't careful.
> > 
> > But we already solved all of that for pathkeys. We keep the paths
> > around if there's a reason to (a useful pathkey) and there's not
> > some
> > other cheaper path that also satisfies the same reason.
> 
> But we've already solved it for this case, too. This is exactly what
> incrementing disabled_nodes does.

Hints are often described as something positive: use this index, use a
hash join here, etc. Trying to force a positive thing by adding
negative attributes to everything else is awkward. We've all had the
experience where we disable one plan type hoping for a good plan, and
we end up getting a different crazy plan that we didn't expect, and
need to disable a few more plan types.

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?

Regards,
	Jeff Davis

---

From: Tom Lane <[email-masked]>
Date: Wed, 28 Aug 2024 19:25:59 -0400

> CustomScan. How is the hints extension supposed to disable a path it

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.

			regards, tom lane

---

From: Michael Paquier <[email-masked]>
Date: Thu, 29 Aug 2024 09:28:46 +0900

> > CustomScan. How is the hints extension supposed to disable a path it

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/[email-masked]

> 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