public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Tom Lane <[email protected]>
Cc: Jeff Davis <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: allowing extensions to control planner behavior
Date: Thu, 29 Aug 2024 09:28:46 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CA+TgmoZY+baV-T-5ifDn6P=L=aV-VkVBrPmi0TQkcEq-5Finww@mail.gmail.com>
<[email protected]>
<CA+TgmoY4yBRawLY-u0GM6aW7f0N4W8RU8WsZRb5+qhpWWfmZcQ@mail.gmail.com>
<[email protected]>
<[email protected]>
On Wed, Aug 28, 2024 at 07:25:59PM -0400, Tom Lane wrote:
> Jeff Davis <[email protected]> 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/[email protected]
> 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
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (4+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: allowing extensions to control planner behavior
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox