Re: postgres_fdw bug in 9.6

>
> 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 generate a nestloop path.
and
* If either cheapest-total path is parameterized by the other
* rel, we can't generate a hashjoin/mergejoin path. (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 already well 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