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_ohjxq9wgt...@mail.gmail.com Discussion: http://postgr.es/m/CA+TgmoYS4ZCVAF2jTce=bmp0oq_db_srocr4czyo0obp9ou...@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/cbdf93d4712229fd82d40d823882a5bc84e407e5 Modified Files -------------- src/backend/optimizer/path/costsize.c | 5 ----- src/backend/optimizer/path/joinpath.c | 11 ++++++++++- src/backend/optimizer/plan/createplan.c | 4 ---- 3 files changed, 10 insertions(+), 10 deletions(-)
