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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers