On 2017/01/11 17:51, Ashutosh Bapat wrote:
On Wed, Jan 11, 2017 at 1:15 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
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?
It's not guaranteed that we will always have foreign join paths there.
We have seen this in Jeff's example, which started this thread. We
don't know in what all cases we have a tree entirely consisting of
(cheapest) foreign join paths.
Right, but local-join plans need not be efficient since no base table
will return more than one row, as stated in the documentation. (I think
efficient plans without complicating the code would be better, though.)
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.
Peformance wise it is, correctness-wise it is not. Why do we want to
incur a hop, when we can avoid it.
ISTM that's solving a problem that hasn't been proven to be a problem.
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].
I don't agree that pathlists will be long enough to make this a
non-attractive solution. For parameterized foreign join paths, with
the approach that this patch takes, we will require to search in two
such pathlists, inner and outer.
Sorry, I don't understand this part.
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
