On 2017/01/05 13:19, 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.
>> I think that would simplify the code as well.
> Creating a new path 1. requires memory
The search approach would require memory for saving the path, too.
> 2. spends CPU cycles in costing
> and creating it
The search approach would also need extra cycles in the cases mentioned
in [1], wouldn't it? Since it would be useless to cost the
fdw_outerpath of a foreign join, we could skip that for the
fdw_outerpath if necessary.
> 3. requires a search in inner and outer relations'
> pathlists (see my earlier reply).
What I'm thinking is basically to use the cheapest-total-cost paths of
the inner/outer relations, which wouldn't require any search.
Best regards,
Etsuro Fujita
[1]
https://www.postgresql.org/message-id/c1075e4e-8297-5cf6-3f30-cb21266aa2ee%40lab.ntt.co.jp