From: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com> |
Subject: | Re: Foreign join pushdown vs EvalPlanQual |
Date: | 2015-11-07 15:37:59 |
Message-ID: | 9A28C8860F777E439AA12E8AEA7694F801163E8D@BPXM15GP.gisp.nec.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Fri, Nov 6, 2015 at 9:42 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> > This patch needs to be rebased.
> > One thing different from the latest version is fdw_recheck_quals of
> > ForeignScan was added. So, ...
> >
> > (1) Principle is that FDW driver knows what qualifiers were pushed down
> > and how does it kept in the private field. So, fdw_recheck_quals is
> > redundant and to be reverted.
> >
> > (2) Even though the principle is as described in (1), however,
> > wired logic in ForeignRecheck() and fdw_recheck_quals are useful
> > default for most of FDW drivers. So, it shall be kept and valid
> > only if RecheckForeignScan callback is not defined.
> >
> > Which is better approach for the v3 patch?
> > My preference is (1), because fdw_recheck_quals is a new feature,
> > thus, FDW driver has to be adjusted in v9.5 more or less, even if
> > it already supports qualifier push-down.
> > In general, interface becomes more graceful to stick its principle.
>
> fdw_recheck_quals seems likely to be very convenient for FDW authors,
> and I think ripping it out would be a terrible decision.
>
OK, I try to co-exist fdw_recheck_quals and RecheckForeignScan callback.
> I think ForeignRecheck should first call ExecQual to test
> fdw_recheck_quals. If it returns false, return false. If it returns
> true, then give the FDW callback a chance, if one is defined. If that
> returns false, return false. If we haven't yet returned false,
> return true.
>
I think ExecQual on fdw_recheck_quals shall be called next to the
RecheckForeignScan callback, because econtext->ecxt_scantuple shall
not be reconstructed unless RecheckForeignScan callback is not called
if scanrelid==0.
If RecheckForeignScan is called prior to ExecQual, FDW driver can
take either of two options according to its preference.
(1) RecheckForeignScan callback reconstruct a joined tuple based on
the primitive EPQ slots, but nothing are rechecked by itself.
ForeignRecheck runs ExecQual on fdw_recheck_quals that represents
qualifiers of base relations and join condition.
(2) RecheckForeignScan callback reconstruct a joined tuple based on
the primitive EPQ slots, then rechecks qualifiers of base relations
and join condition by itself. It put NIL on fdw_recheck_quals, so
ExecQual in ForeignRecheck() always true.
In either case, we cannot use ExecQual prior to reconstruction of
a joined tuple because only FDW driver knows how to reconstruct it.
So, it means ForeignScan with scanrelid==0 always has to set NIL on
fdw_recheck_quals, if we would put ExecQual prior to the callback.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-11-07 16:52:17 | Re: Summary of Vienna sharding summit, new TODO item |
Previous Message | Praveen M | 2015-11-07 15:21:41 | Need to print the raw_parse_tree in the Log file |