Re: pg_plan_advice - Mailing list pgsql-hackers

From Lukas Fittl
Subject Re: pg_plan_advice
Date
Msg-id CAP53PkywaZbptzC1f-43pUrVwk5U9ARRKUF+E+ZGpKsnPhBFVg@mail.gmail.com
Whole thread Raw
In response to Re: pg_plan_advice  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg_plan_advice
List pgsql-hackers
On Thu, Jan 8, 2026 at 10:22 AM Robert Haas <robertmhaas@gmail.com> wrote:
> 0004: Comment update, bug fix to cost_index() per comment from Lukas.

Thanks! I've tested this and this works as expected on current master
with the updated pg_hint_plan code, and checking for tablesample in
the code that sets the mask.

On Thu, Jan 8, 2026 at 8:38 AM Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Jan 8, 2026 at 11:31 AM Lukas Fittl <lukas@fittl.com> wrote:
> > Yeah, I would agree with you that is inconsistent with the flag's name
> > - but on the flip side, its difficult for the caller to conditionally
> > set the flag (which you'd have to do to avoid a "Disabled" showing in
> > the plan), since we're setting it on the RelOptInfo (do we know if the
> > scan is a sample scan at that point?).
>
> How about checking rte->tablesample, as set_rel_pathlist does?

Yeah, that works - its a bit inconvenient for two reasons, but I don't
think that warrants a redesign:

1) get_relation_info_hook doesn't get a RangeTblEntry passed (like
set_rel_pathlist_hook), but that's solvable by looking it up via
simple_rte_array
2) It requires maintaining a special case in the logic that says "make
it parallel", vs the planner that is authoritative (i.e. if we add
more special cases in the future, each extension will have to be
updated to reflect that)

Thanks,
Lukas

--
Lukas Fittl



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fixing the btree_gist inet mess
Next
From: Tom Lane
Date:
Subject: Re: Proposal to allow setting cursor options on Portals