Re: Foreign join pushdown vs EvalPlanQual

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, 花田茂 <shigeru(dot)hanada(at)gmail(dot)com>
Subject: Re: Foreign join pushdown vs EvalPlanQual
Date: 2015-08-01 14:25:59
Message-ID: 12657.1438439159@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-08-01 15:14:10 No more libedit?! - openssl plans to switch to APL2
Previous Message Rahila Syed 2015-08-01 14:25:40 Re: [PROPOSAL] VACUUM Progress Checker.