|From:||Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>|
|To:||Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>|
|Cc:||"pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "shigeru(dot)hanada(at)gmail(dot)com" <shigeru(dot)hanada(at)gmail(dot)com>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>|
|Subject:||Re: Foreign join pushdown vs EvalPlanQual|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>> On 2015/10/15 11:36, Kouhei Kaigai wrote:
>>> 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
>> 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.
On 2015/10/15 20:19, Kouhei Kaigai wrote:
> I have to introduce why above idea is simpler and suitable for v9.5
> As I've consistently proposed for this two months, the step-2 and 3
> are assumed to be handled in the callback routine to be kicked from
Honestly, I still don't think I would see the much value in doing so.
As Robert mentioned in , I think that if we're inside EPQ,
pushed-down quals and/or pushed-down joins should be locally rechecked
in the same way as other cases such as IndexRecheck. So, I'll propose
the updated version of the patch.
Thanks for the explanation!
|Next Message||Etsuro Fujita||2015-10-16 09:00:45||Re: Foreign join pushdown vs EvalPlanQual|
|Previous Message||Pavel Stehule||2015-10-16 07:10:12||Re: proposal: PL/Pythonu - function ereport|