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

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to