Robert Haas <robertmh...@gmail.com> writes: > 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.
In principle it seems like you could traverse root->parse->jointree as a guide to reconstructing the original syntactic structure; though I'm not sure how hard it would be to ignore the parts of that tree that correspond to relations you're not shipping. > 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. In my vision you probably really only want one call per build_join_rel event (that is, per construction of a new RelOptInfo), not per make_join_rel event. It's possible that an FDW that wants to handle joins but is not talking to a remote query planner would need to grovel through all the join ordering possibilities individually, and then maybe hooking at make_join_rel is sensible rather than having to reinvent that logic. But I'd want to see a concrete use-case first, and I certainly don't think that that's the main case to design the API around. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers