On Tue, Sep 8, 2015 at 5:35 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > 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.
But that path might have already been discarded on the basis of cost. I think Tom's idea is better: let the FDW consult some state cached for this purpose in the RelOptInfo. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
