Re: Foreign join pushdown vs EvalPlanQual

From: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: 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 13:34:56
Message-ID: 9A28C8860F777E439AA12E8AEA7694F8011217DA@BPXM15GP.gisp.nec.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Fri, Jul 3, 2015 at 6:25 AM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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 <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Harris 2015-08-01 13:49:44 Re: Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"
Previous Message Kouhei Kaigai 2015-08-01 13:09:50 Re: [DESIGN] ParallelAppend