public inbox for [email protected]
help / color / mirror / Atom feedRe: pg_plan_advice
2+ messages / 2 participants
[nested] [flat]
* Re: pg_plan_advice
@ 2026-01-08 23:29 Michael Paquier <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Michael Paquier @ 2026-01-08 23:29 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Lukas Fittl <[email protected]>; Jacob Champion <[email protected]>; Dian Fay <[email protected]>; Matheus Alcantara <[email protected]>; Jakub Wartak <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Jan 08, 2026 at 11:07:31AM -0500, Robert Haas wrote:
> On Wed, Jan 7, 2026 at 2:04 AM Lukas Fittl <[email protected]> wrote:
>> That said, good news: After a bunch of iterations, I get a clean
>> pass on the pg_hint_plan regression tests, whilst completely
>> dropping its copying of core code and hackish re-run of
>> set_plain_rel_pathlist. See [0] for a draft PR (on my own fork of
>> pg_hint_plan) with individual patches that explain some regression
>> test differences.
>
> That sounds AWESOME.
So you are telling me that I can commit code that deletes code. Count
me in. The project has some merge requests that I've been holding on
a bit due to what's happening here and because I did not really look
at the internals that have changed. It's great to see that you have
begun an investigation, Lukas.
>> The biggest change in the regression test output was due to how the
>> "Parallel" hint worked in pg_hint_plan (basically it was setting
>> parallel_*_cost to zero, and then messed with the gucs that factor
>> into compute_parallel_worker) -- I think the only sensible thing to
>> do is to change that in pg_hint_plan, and instead rely on rejecting
>> non-partial paths with PGS_CONSIDER_NONPARTIAL if "hard"
>> enforcement of parallelism is requested. That caused some minor
>> plan changes, but I think they can still be argued to be matching
>> the user's intent of "make a scan involving this relation
>> parallel".
>
> Cool. I'm sort of curious what changed, but maybe it's not important
> enough to spend time discussing right now.
I suspect that this is going to be an incremental integration process,
and it smells to me that it is going to require more than one major
release before being able to remove the whole set of hacks that
pg_hint_plan has been using, particularly with the GUCs, the costing
and the forced update of the backend routines which is a ugly
historical hack. Saying that, I would need to look at the plan
outputs to be sure, perhaps we would be OK even with slight changes.
These happen every year, because the plans tested are complex enough
that some of the sub-paths are changed, but the hints still work
properly. This year for v19 we have at least the changes in the
expression names.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: pg_plan_advice
@ 2026-01-12 14:50 Robert Haas <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Robert Haas @ 2026-01-12 14:50 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Lukas Fittl <[email protected]>; Jacob Champion <[email protected]>; Dian Fay <[email protected]>; Matheus Alcantara <[email protected]>; Jakub Wartak <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Jan 8, 2026 at 6:29 PM Michael Paquier <[email protected]> wrote:
> So you are telling me that I can commit code that deletes code. Count
> me in. The project has some merge requests that I've been holding on
> a bit due to what's happening here and because I did not really look
> at the internals that have changed. It's great to see that you have
> begun an investigation, Lukas.
:-)
> I suspect that this is going to be an incremental integration process,
> and it smells to me that it is going to require more than one major
> release before being able to remove the whole set of hacks that
> pg_hint_plan has been using, particularly with the GUCs, the costing
> and the forced update of the backend routines which is a ugly
> historical hack. Saying that, I would need to look at the plan
> outputs to be sure, perhaps we would be OK even with slight changes.
> These happen every year, because the plans tested are complex enough
> that some of the sub-paths are changed, but the hints still work
> properly. This year for v19 we have at least the changes in the
> expression names.
I think it's quite possible that you could do a full rip and replace
with some study of what needs to be added on top of 0004. The core
idea of 0004 is that it adds a field called pgs_mask in several of
places, which allows you to set a bitmask to control which operations
the planner will consider to be enabled. You can set this via some
existing hooks, and it also adds a a new hook (joinrel_setup_hook)
which is called near the start of add_paths_to_joinrel(). So, you can
set pgs_mask in PlannerGlobal to control planning for the entire
operation, RelOptInfo to control it for a particular rel, or
JoinPathExtraData to set it for a particular joinrel and a particular
choice of outer and inner rel. I am pretty well convinced that this is
a good model: instead of duplicating a bunch of planner code, as
pg_hint_plan currently does, just have a way to tell the existing
planner code what you want it to do.
Now, one fly in the ointment is that pgs_mask is just a mask -- that
is, it gives us space to store 64 related Booleans, but nothing else.
So if we want to store an integer, like a number of parallel workers,
we need a separate field for that. But if that integer can reasonably
be set at the same levels that are possible for pgs_mask, it's really
easy: just look at the places where 0004 adds a pgs_mask field, and
add an integer field as well. There is obviously some limit to the
number of fields we can reasonably add to PlannerGlobal, RelOptInfo,
and JoinPathExtraData, but if it starts to become too much, we could
bundle some or all of them up in a struct. The patch has already
figured out how to get the mask to propagate down to the places where
low-level planning decisions are being made, so it seems worth trying
to piggy-back on that for anything else that we need.
Now, maybe that won't work out for some reason. But on the other hand,
maybe it will work out. I think it's possible that for the price of a
quite small patch adding another field or a couple of fields on top of
pgs_mask and in the same places, you could get rid of a lot more code.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-01-12 14:50 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-01-08 23:29 Re: pg_plan_advice Michael Paquier <[email protected]>
2026-01-12 14:50 ` Robert Haas <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox