]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix PGS_CONSIDER_NONPARTIAL interaction with Materialize nodes.
authorRobert Haas <rhaas@postgresql.org>
Tue, 10 Feb 2026 16:49:07 +0000 (11:49 -0500)
committerRobert Haas <rhaas@postgresql.org>
Tue, 10 Feb 2026 16:49:07 +0000 (11:49 -0500)
commitcbdf93d4712229fd82d40d823882a5bc84e407e5
tree2c00a965ec72d0c09e0633491d92417d3d8d4426
parentbe5257725d7f65708f5955a3a4beaedaa370e45b
Fix PGS_CONSIDER_NONPARTIAL interaction with Materialize nodes.

Commit 4020b370f214315b8c10430301898ac21658143f had the idea that it
would be a good idea to handle testing PGS_CONSIDER_NONPARTIAL within
cost_material to save callers the trouble, but that turns out not to be
a very good idea. One concern is that it makes cost_material() dependent
on the caller having initialized certain fields in the MaterialPath,
which is a bit awkward for materialize_finished_plan, which wants to use
a dummy path.

Another problem is that it can result in generated materialized nested
loops where the Materialize node is disabled, contrary to the intention
of joinpath.c's logic in match_unsorted_outer() and
consider_parallel_nestloop(), which aims to consider such paths only
when they would not need to be disabled. In the previous coding, it was
possible for the pgs_mask on the joinrel to have PGS_CONSIDER_NONPARTIAL
set, while the inner rel had the same bit clear. In that case, we'd
generate and then disable a Materialize path.

That seems wrong, so instead, pull up the logic to test the
PGS_CONSIDER_NONPARTIAL bit into joinpath.c, restoring the historical
behavior that either we don't generate a given materialized nested loop
in the first place, or we don't disable it.

Discussion: http://postgr.es/m/CA+TgmoawzvCoZAwFS85tE5+c8vBkqgcS8ZstQ_ohjXQ9wGT9sw@mail.gmail.com
Discussion: http://postgr.es/m/CA+TgmoYS4ZCVAF2jTce=bMP0Oq_db_srocR4cZyO0OBp9oUoGg@mail.gmail.com
src/backend/optimizer/path/costsize.c
src/backend/optimizer/path/joinpath.c
src/backend/optimizer/plan/createplan.c