Robert Haas <robertmhaas@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
