When looking at try_partial_hashjoin_path and try_partial_nestloop_path functions I'm failing to understand the comment "Parameterized partial paths are not supported.".
It's clear to me that GatherPath can't have parameters because repeated execution of parallel plan with adjusted parameters is not supported. But the fact that generic partial path has parameters should not be a problem if those parameters are satisfied below the nearest GatherPath node higher in the plan tree. Do I miss anything of the concept? Actually this check if (!bms_is_subset(inner_paramrels, outer_path->parent->relids)) return; in try_partial_nestloop_path only rejects special case where the inner path references relations outside the join, but still allows the outer path to have parameters outside. As for try_partial_hashjoin_path, the comment "If the inner path is parameterized ..." seems to be copy & pasted from try_partial_nestloop_path, but I think it does not fit hash join. From hash_inner_and_outer I judge that neither side of hash join can be parameterized by the other: /* * If either cheapest-total path is parameterized by the other rel, we * can't use a hashjoin. (There's no use looking for alternative * input paths, since these should already be the least-parameterized * available paths.) */ if (PATH_PARAM_BY_REL(cheapest_total_outer, innerrel) || PATH_PARAM_BY_REL(cheapest_total_inner, outerrel)) return; Shouldn't try_partial_hashjoin_path and try_partial_nestloop_path do just the same checks that try_hashjoin_path and try_nestloop_path do respectively? -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers