Re: Foreign join pushdown vs EvalPlanQual

Поиск
Список
Период
Сортировка
От Kouhei Kaigai
Тема Re: Foreign join pushdown vs EvalPlanQual
Дата
Msg-id 9A28C8860F777E439AA12E8AEA7694F8011217DA@BPXM15GP.gisp.nec.co.jp
обсуждение исходный текст
Ответ на Re: Foreign join pushdown vs EvalPlanQual  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Foreign join pushdown vs EvalPlanQual
Список pgsql-hackers
> On Fri, Jul 3, 2015 at 6:25 AM, Etsuro Fujita
> <fujita.etsuro@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 <kaigai@ak.jp.nec.com>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kouhei Kaigai
Дата:
Сообщение: Re: [DESIGN] ParallelAppend
Следующее
От: Jeremy Harris
Дата:
Сообщение: Re: Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"