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