>
> Done. Attached is the new version of the patch.
>
> * I'm still not sure the search approach is the right way to go, so I
> modified CreateLocalJoinPath so that it creates a mergejoin path that
> explicitly sorts both the outer and inner relations as in
> sort_inner_and_outer, by using the information saved in that function. I
> think we could try to create a sort-free mergejoin as in
> match_unsorted_outer, but I'm not sure it's worth complicating the code.
Why is this so? * If the outer cheapest-total path is parameterized by the inner * rel, we can't
generatea nestloop path.
and * If either cheapest-total path is parameterized by the other * rel, we can't generate a
hashjoin/mergejoinpath. (There's no
If the inner and/or outer paths are not ordered as required, we will need to
order them. Code below doesn't seem to handle that case. /* * If the paths are
alreadywell enough ordered, we can * skip doing an explicit sort. */
if (outerkeys && pathkeys_contained_in(outerkeys, outer_path->pathkeys))
outerkeys = NIL; if (innerkeys && pathkeys_contained_in(innerkeys,
inner_path->pathkeys)) innerkeys = NIL;
> * I modified CreateLocalJoinPath so that it handles the cheapest-total paths
> for the outer/inner relations that are parameterized if possible.
I don't think we need to provide details of what kind of path the function
builds.
+ join plan. <literal>CreateLocalJoinPath</> builds a nested loop join
+ path for the specified join relation, except when the join type is
+ <literal>FULL</>, in which case a merge or hash join path is built.
I am not able to understand the code or the comment below
+
+ /* Save first mergejoin information for possible use by the FDW */
+ if (outerkeys == all_pathkeys)
+ {
+ extra->mergeclauses = cur_mergeclauses;
+ extra->merge_pathkeys = merge_pathkeys;
+ extra->merge_outerkeys = outerkeys;
+ extra->merge_innerkeys = innerkeys;
+ }
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company