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
foralternative* 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