pgsql: Allow for plugin control over path generation strategies.
Allow for plugin control over path generation strategies.
Each RelOptInfo now has a pgs_mask member which is a mask of acceptable
strategies. For most rels, this is populated from PlannerGlobal's
default_pgs_mask, which is computed from the values of the enable_*
GUCs at the start of planning.
For baserels, get_relation_info_hook can be used to adjust pgs_mask for
each new RelOptInfo, at least for rels of type RTE_RELATION. Adjusting
pgs_mask is less useful for other types of rels, but if it proves to
be necessary, we can revisit the way this hook works or add a new one.
For joinrels, two new hooks are added. joinrel_setup_hook is called each
time a joinrel is created, and one thing that can be done from that hook
is to manipulate pgs_mask for the new joinrel. join_path_setup_hook is
called each time we're about to add paths to a joinrel by considering
some particular combination of an outer rel, an inner rel, and a join
type. It can modify the pgs_mask propagated into JoinPathExtraData to
restrict strategy choice for that particular combination of rels.
To make joinrel_setup_hook work as intended, the existing calls to
build_joinrel_partition_info are moved later in the calling functions;
this is because that function checks whether the rel's pgs_mask includes
PGS_CONSIDER_PARTITIONWISE, so we want it to only be called after
plugins have had a chance to alter pgs_mask.
Upper rels currently inherit pgs_mask from the input relation. It's
unclear that this is the most useful behavior, but at the moment there
are no hooks to allow the mask to be set in any other way.
Reviewed-by: Lukas Fittl <lukas@fittl.com>
Reviewed-by: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Greg Burd <greg@burd.me>
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Haibo Yan <tristan.yim@gmail.com>
Discussion: /messages/by-id/CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/4020b370f214315b8c10430301898ac21658143f
Modified Files
--------------
src/backend/optimizer/path/allpaths.c | 2 +-
src/backend/optimizer/path/costsize.c | 222 +++++++++++++++++++++++++-------
src/backend/optimizer/path/indxpath.c | 4 +-
src/backend/optimizer/path/joinpath.c | 89 +++++++++----
src/backend/optimizer/path/tidpath.c | 7 +-
src/backend/optimizer/plan/createplan.c | 4 +-
src/backend/optimizer/plan/planner.c | 54 ++++++++
src/backend/optimizer/util/pathnode.c | 19 ++-
src/backend/optimizer/util/plancat.c | 3 +
src/backend/optimizer/util/relnode.c | 44 +++++--
src/include/nodes/pathnodes.h | 82 +++++++++++-
src/include/optimizer/cost.h | 4 +-
src/include/optimizer/pathnode.h | 12 +-
src/include/optimizer/paths.h | 9 +-
14 files changed, 457 insertions(+), 98 deletions(-)
Hi Robert,
On Wed, Jan 28, 2026 at 05:08:03PM +0000, Robert Haas wrote:
Allow for plugin control over path generation strategies.
I am not sure what is going on here, but skink has gone rogue since
this has been committed. The first failure of this animal points to
this commit:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2026-01-28%2017%3A12%3A26
Some details from postmaster.log:
==2296443== Conditional jump or move depends on uninitialised value(s)
==2296443== at 0x434D3E6: cost_material (costsize.c:2593)
==2296443== by 0x436E869: materialize_finished_plan (createplan.c:6531)
[...]
**2296443** Valgrind detected 1 error(s) during execution of "explain
(costs off) declare c1 scroll cursor for select (select 42) as x;"
**2296443** Valgrind detected 1 error(s) during execution of "declare
c1 scroll cursor for select (select 42) as x;"
So it looks like this is missing some initialization, causing valgrind
to complain.
--
Michael
On Wed, Jan 28, 2026 at 11:51 PM Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Jan 28, 2026 at 05:08:03PM +0000, Robert Haas wrote:
Allow for plugin control over path generation strategies.
I am not sure what is going on here, but skink has gone rogue since
this has been committed.
Thanks for the report. 4020b370f214315b8c10430301898ac21658143f
includes an attempt at a fix.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi,
Some details from postmaster.log:
==2296443== Conditional jump or move depends on uninitialised value(s)
==2296443== at 0x434D3E6: cost_material (costsize.c:2593)
==2296443== by 0x436E869: materialize_finished_plan (createplan.c:6531)
[...]
**2296443** Valgrind detected 1 error(s) during execution of "explain
(costs off) declare c1 scroll cursor for select (select 42) as x;"
**2296443** Valgrind detected 1 error(s) during execution of "declare
c1 scroll cursor for select (select 42) as x;"So it looks like this is missing some initialization, causing valgrind
to complain.
I tested an alternative solution based on memset() and it makes
Valgrind happy (tested on Linux x64), while all the tests pass.
--
Best regards,
Aleksander Alekseev
Attachments:
v1-0001-Initialize-mathpath-variable-in-materialize_finis.patchapplication/x-patch; name=v1-0001-Initialize-mathpath-variable-in-materialize_finis.patchDownload+1-3
Hi Robert,
Thanks for the report. 4020b370f214315b8c10430301898ac21658143f
includes an attempt at a fix.
Not sure if keeping unitized structure is a good solution in the long
run. However if you are aiming for performance instead of:
```
+ /* Clear fields that cost_material() will consult */
+ matpath.parallel_workers = 0;
matpath.parent = NULL;
```... you could just rewrite the `if` condition in cost_material():
```
if (path->parent != NULL && /* <--- is false */
path->parallel_workers == 0 &&
```
--
Best regards,
Aleksander Alekseev
On Thu, Jan 29, 2026 at 8:53 AM Aleksander Alekseev
<aleksander@tigerdata.com> wrote:
... you could just rewrite the `if` condition in cost_material():
```
if (path->parent != NULL && /* <--- is false */
path->parallel_workers == 0 &&
```
In the interest of keeping the discussion unified, can we move this
part of the conversation over to the pg_plan_advice thread? Lukas
Fittl has also posted about this topic over there.
--
Robert Haas
EDB: http://www.enterprisedb.com