Re: Foreign join pushdown vs EvalPlanQual - Mailing list pgsql-hackers

From Kouhei Kaigai
Subject Re: Foreign join pushdown vs EvalPlanQual
Date
Msg-id 9A28C8860F777E439AA12E8AEA7694F8011727E1@BPXM15GP.gisp.nec.co.jp
Whole thread Raw
In response to Foreign join pushdown vs EvalPlanQual  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: Foreign join pushdown vs EvalPlanQual
Re: Foreign join pushdown vs EvalPlanQual
List pgsql-hackers
> On Sun, Nov 8, 2015 at 7:26 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> > The attached patch is an adjusted version of the previous one.
> > Even though it co-exists a new callback and fdw_recheck_quals,
> > the callback is kicked first as follows.
> 
> This seems excessive to me: why would we need an arbitrary-length list
> of plans for an FDW?  I think we should just allow an outer child and
> an inner child, which is probably one more than we'll ever need in
> practice.
>
It just intends to keep code symmetry with custom-scan case, so not
a significant reason.
And, I expected ForeignScan will also need multiple sub-plans soon
to support more intelligent push-down like:
http://www.postgresql.org/message-id/9A28C8860F777E439AA12E8AEA7694F8010F47DA@BPXM15GP.gisp.nec.co.jp

It is a separate discussion, of course, so I don't have strong preference
here.

> This looks like an independent bug fix:
> 
> +               fscan->fdw_recheck_quals = (List *)
> +                       fix_upper_expr(root,
> +                                                  (Node *)
> fscan->fdw_recheck_quals,
> +                                                  itlist,
> +                                                  INDEX_VAR,
> +                                                  rtoffset);
>                 pfree(itlist);
> 
> If so, it should be committed separately and back-patched to 9.5.
>
OK, I'll split the patch into two.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?
Next
From: Tom Lane
Date:
Subject: Re: Bug in numeric multiplication