Re: Foreign join pushdown vs EvalPlanQual
От | Etsuro Fujita |
---|---|
Тема | Re: Foreign join pushdown vs EvalPlanQual |
Дата | |
Msg-id | 561F7932.6090306@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Foreign join pushdown vs EvalPlanQual (Kouhei Kaigai <kaigai@ak.jp.nec.com>) |
Ответы |
Re: Foreign join pushdown vs EvalPlanQual
(Kouhei Kaigai <kaigai@ak.jp.nec.com>)
|
Список | pgsql-hackers |
On 2015/10/15 11:36, Kouhei Kaigai wrote: >>> Once again, if FDW driver is responsible to construct join-tuple from >>> the base relation's tuple cached in EPQ slot, this case don't need to >>> kick remote query again, because all the materials to construct join- >>> tuple are already held locally. Right? I now understand clearly what you mean. Sorry for my misunderstanding. > In case of scanrelid==0, expectation to ForeignScan/CustomScan is to > behave as if local join exists here. It requires ForeignScan to generate > joined-tuple as a result of remote join, that may contains multiple junk > TLEs to carry whole-var references of base foreign tables. > According to the criteria, the desirable behavior is clear as below: > > 1. FDW/CSP picks up base relation's tuple from the EPQ slots. > It shall be setup by whole-row reference if earlier row-lock semantics, > or by RefetchForeignRow if later row-lock semantics. > > 2. Fill up ss_ScanTupleSlot according to the xxx_scan_tlist. > We may be able to provide a common support function here, because this > list keeps relation between a particular attribute of the joined-tuple > and its source column. > > 3. Apply join-clause and base-restrict that were pushed down. > setrefs.c initializes expressions kept in fdw_exprs/custom_exprs to run > on the ss_ScanTupleSlot. It is the easiest way to check here. > > 4. If joined-tuple is still visible after the step 3, FDW/CSP returns > joined-tuple. Elsewhere, returns an empty slot. > > It is entirely compatible behavior even if local join is located on > the point of ForeignScan/CustomScan with scanrelid==0. > > Even if remote join is parametalized by other relation, we can simply > use param-info delivered from the corresponding outer scan at the step-3. > EState should have the parameters already updated, FDW driver needs to > care about nothing. > > It is quite less invasive approach towards the existing EPQ recheck > mechanism. I see. That's an idea, but I guess that step 2 and 3 would need to add a lot of code to the core. Why don't you use a local join execution plan that we discussed? I think that that would make the series of processing much simpler. I'm now revising the patch that I created for that. If it's okay, I'd like to propose an updated version of the patch in a few days. > I cannot understand why Fujita-san never "try" this approach. Maybe my explanation was not correct, but I didn't say such a thing. What I rather objected against was to add a new FDW callback routine for rechecking pushed-down quals or pushed-down joins, which I think you insisted on. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления:
Следующее
От: Pavel StehuleДата:
Сообщение: Re: How to import PostgreSQL 9.2.4 dump to PostgreSQL 9.4.5?