On 2017/01/11 13:40, Ashutosh Bapat wrote:
CreateLocalJoinPath tries to construct a nestloop path for the given
join relation because it wants to avoid merge/hash join paths which
require expensive setup not required for EPQ. But it chooses cheap
paths for joining relations which may not be nestloop paths. So,
effectively it could happen that the whole alternate local plan would
be filled with hash/merge joins except the uppermost join.
In many cases the cheapest-total-cost outer and inner paths for a higher
foreign-join relation would be foreign join paths, which would have
nestloop paths as their fdw_outerpaths if not full joins. So by
redirection, the plan tree for EPQ would be mostly constructed by
nestloop joins. No?
Or it can
have foreign paths in there, which will need redirection. That's not
very good.
Maybe I'm missing something, but redirection isn't a problem.
We have to choose one of the following
alternatives
1. develop a mechanism to remember epq path for joining relations so
that it's available to CreateLocalJoinPath
2.let the caller pass epq local paths for joining relations to
CreateLocalJoinPath. How it remembers those, is FDW's problem.
I thought such a thing, but I think that would be overcomplicated, as
pointed out by Tom [2].
2. Fix existing code by applying patch from [1]
As I said before, that might be fine for 9.6, but I don't think it's a
good idea to search the pathlist because once we support parameterized
foreign join paths, which is on my TODOs, we would have to traverse
through the possibly-lengthy pathlist to find a local-join path, as
mentioned in [3].
Best regards,
Etsuro Fujita
[2] https://www.postgresql.org/message-id/12565.1481904788%40sss.pgh.pa.us
[3]
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
