Re: postgres_fdw bug in 9.6

On 2017/01/05 12:10, Etsuro Fujita wrote:
> On 2016/12/28 17:34, Ashutosh Bapat wrote:
>> Hmm. If I understand the patch correctly, it does not return any path
>> when merge join is allowed and there are merge clauses but no hash
>> clauses. In this case we will not create a foreign join path, loosing
>> some optimization. If we remove GetExistingLocalJoinPath, which
>> returns a path in those cases as well, we have a regression in
>> performance.

> Ok, will revise, but as I mentioned upthread, I'm not sure it's a good
> idea to search the pathlist to get a merge join even in this case. I'd
> vote for creating a merge join path from the inner/outer paths in this
> case as well.

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.
* I modified CreateLocalJoinPath so that it handles the cheapest-total
paths for the outer/inner relations that are parameterized if possible.
* I adjusted the code and revised some comments.

As I said upthread, we could skip costing for a local join path in
CreateLocalJoinPath, for efficiency, but I'm not sure we should do that.

Best regards,
Etsuro Fujita