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 |
Date: | 2015-10-15 10:00:18 |
Message-ID: | 561F7932.6090306@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2015-10-15 10:04:45 | Re: How to import PostgreSQL 9.2.4 dump to PostgreSQL 9.4.5? |
Previous Message | Victor Wagner | 2015-10-15 09:43:21 | Re: Patch: Implement failover on libpq connect level. |