On 2015/09/04 0:33, Robert Haas wrote:
I'm worried that trawling through that
SpecialJoinInfo data will end up needing to duplicate much of
make_join_rel and add_paths_to_joinrel. For example, consider:
SELECT * FROM verysmall v JOIN (bigft1 FULL JOIN bigft2 ON bigft1.x =
bigft2.x) ON v.q = bigft1.q AND v.r = bigft2.r;
The best path for this plan is presumably something like this:
Nested Loop
-> Seq Scan on verysmall v
-> Foreign Scan on bigft1 and bigft2
Remote SQL: SELECT * FROM bigft1 FULL JOIN bigft2 ON bigft1.x =
bigft2.x AND bigft1.q = $1 AND bigft2.r = $2
Now, how is the FDW going to figure out that it needs to generate this
parameterized path without duplicating this code from
add_paths_to_joinrel?
/*
* Decide whether it's sensible to generate parameterized paths for this
* joinrel, and if so, which relations such paths should require. There
* is usually no need to create a parameterized result path unless there
...
Maybe there's a very simple answer to this question and I'm just not
seeing it, but I really don't see how that's going to work.
Why don't you look at the "regular" (local join execution) paths that
were already generated. I think that if we called the FDW at a proper
hook location, the FDW could probably find a regular path in
rel->pathlist of the join rel (bigft1, bigft2) that possibly generates
something like:
Nested Loop
-> Seq Scan on verysmall v
-> Nested Loop
Join Filter: (bigft1.a = bigft2.a)
-> Foreign Scan on bigft1
Remote SQL: SELECT * FROM bigft1 WHERE bigft1.q = $1
-> Foreign Scan on bigft2
Remote SQL: SELECT * FROM bigft2 WHERE bigft2.r = $2
From the parameterization of the regular nestloop path for joining
bigft1 and bigft2 locally, I think that the FDW could find that it's
sensible to generate the foreign-join path for (bigft1, bigft2) with the
parameterization.
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
