pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Allow for plugin control over path generation strategies.
6+ messages / 4 participants
[nested] [flat]
Commits from this thread:
2026-01-29 71c1136989 Fix mistakes in commit 4020b370f214315b8c10430301898ac21658143f
* pgsql: Allow for plugin control over path generation strategies.
@ 2026-01-28 17:08 Robert Haas <rhaas@postgresql.org>
0 siblings, 1 reply; 6+ messages in thread
From: Robert Haas @ 2026-01-28 17:08 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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: http://postgr.es/m/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(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pgsql: Allow for plugin control over path generation strategies.
@ 2026-01-29 04:51 Michael Paquier <michael@paquier.xyz>
parent: Robert Haas <rhaas@postgresql.org>
0 siblings, 2 replies; 6+ messages in thread
From: Michael Paquier @ 2026-01-29 04:51 UTC (permalink / raw)
To: Robert Haas <rhaas@postgresql.org>; +Cc: pgsql-committers@lists.postgresql.org
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
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pgsql: Allow for plugin control over path generation strategies.
@ 2026-01-29 13:34 Robert Haas <robertmhaas@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
1 sibling, 1 reply; 6+ messages in thread
From: Robert Haas @ 2026-01-29 13:34 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: pgsql-committers@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pgsql: Allow for plugin control over path generation strategies.
@ 2026-01-29 13:48 Aleksander Alekseev <aleksander@tigerdata.com>
parent: Michael Paquier <michael@paquier.xyz>
1 sibling, 0 replies; 6+ messages in thread
From: Aleksander Alekseev @ 2026-01-29 13:48 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org; +Cc: Michael Paquier <michael@paquier.xyz>; Robert Haas <rhaas@postgresql.org>
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.patch (application/x-patch, 899B) download
From 14eb37ffae650bf3b33f4274bcd84984c89db607 Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev <aleksander@tigerdata.com>
Date: Thu, 29 Jan 2026 16:11:50 +0300
Subject: [PATCH v1] Initialize mathpath variable in
materialize_finished_plan()
---
src/backend/optimizer/plan/createplan.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c
index c26e841f537..41df7d488bb 100644
--- a/src/backend/optimizer/plan/createplan.c
+++ b/src/backend/optimizer/plan/createplan.c
@@ -6526,8 +6526,7 @@ materialize_finished_plan(Plan *subplan)
subplan->startup_cost -= initplan_cost;
subplan->total_cost -= initplan_cost;
- /* Set cost data */
- matpath.parent = NULL;
+ memset(&matpath, 0, sizeof(matpath));
cost_material(&matpath,
enable_material,
subplan->disabled_nodes,
--
2.43.0
* Re: pgsql: Allow for plugin control over path generation strategies.
@ 2026-01-29 13:53 Aleksander Alekseev <aleksander@tigerdata.com>
parent: Robert Haas <robertmhaas@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Aleksander Alekseev @ 2026-01-29 13:53 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org; +Cc: Robert Haas <robertmhaas@gmail.com>; Michael Paquier <michael@paquier.xyz>
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pgsql: Allow for plugin control over path generation strategies.
@ 2026-01-29 14:11 Robert Haas <robertmhaas@gmail.com>
parent: Aleksander Alekseev <aleksander@tigerdata.com>
0 siblings, 0 replies; 6+ messages in thread
From: Robert Haas @ 2026-01-29 14:11 UTC (permalink / raw)
To: Aleksander Alekseev <aleksander@tigerdata.com>; +Cc: pgsql-committers@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
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
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-01-29 14:11 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-01-28 17:08 pgsql: Allow for plugin control over path generation strategies. Robert Haas <rhaas@postgresql.org>
2026-01-29 04:51 ` Michael Paquier <michael@paquier.xyz>
2026-01-29 13:34 ` Robert Haas <robertmhaas@gmail.com>
2026-01-29 13:53 ` Aleksander Alekseev <aleksander@tigerdata.com>
2026-01-29 14:11 ` Robert Haas <robertmhaas@gmail.com>
2026-01-29 13:48 ` Aleksander Alekseev <aleksander@tigerdata.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox