> On Fri, Jul 3, 2015 at 6:25 AM, Etsuro Fujita > <fujita.ets...@lab.ntt.co.jp> wrote: > > Can't FDWs get the join information through the root, which I think we would > > pass to the API as the argument? > > This is exactly what Tom suggested originally, and it has some appeal, > but neither KaiGai nor I could see how to make it work . Do you have > an idea? It's not too late to go back and change the API. > > The problem that was bothering us (or at least what was bothering me) > is that the PlannerInfo provides only a list of SpecialJoinInfo > structures, which don't directly give you the original join order. In > fact, min_righthand and min_lefthand are intended to constraint the > *possible* join orders, and are deliberately designed *not* to specify > a single join order. If you're sending a query to a remote PostgreSQL > node, you don't want to know what all the possible join orders are; > it's the remote side's job to plan the query. You do, however, need > an easy way to identify one join order that you can use to construct a > query. It didn't seem easy to do that without duplicating > make_join_rel(), which seemed like a bad idea. > > But maybe there's a good way to do it. Tom wasn't crazy about this > hook both because of the frequency of calls and also because of the > long argument list. I think those concerns are legitimate; I just > couldn't see how to make the other way work. > I could have a discussion with Fujita-san about this topic. He has a little bit tricky, but I didn't have a clear reason to deny, idea to tackle this matter. At the line just above set_cheapest() of the standard_join_search(), at least one built-in join logic are already added to the RelOptInfo, thus, FDW driver can reference the cheapest path by built-in logic and its lefttree and righttree that construct a joinrel. Its assumption is, the best paths by built-in logic are at least enough reasonable join order than other potential ones.
Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
