Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it? - Mailing list pgsql-hackers

From Kouhei Kaigai
Subject Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?
Date
Msg-id 9A28C8860F777E439AA12E8AEA7694F80111B809@BPXM15GP.gisp.nec.co.jp
Whole thread Raw
In response to Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?
List pgsql-hackers
> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Robert Haas
> Sent: Wednesday, July 22, 2015 11:19 PM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Etsuro Fujita; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] fdw_scan_tlist for foreign table scans breaks EPQ testing,
> doesn't it?
> 
> On Wed, Jul 22, 2015 at 8:13 AM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> >> No, what I'm concerned about is the case when scanrelid > 0.
> >>
> > Hmm. if scanrelid > 0, then fdw_scan_tlist should be NIL.
> > I want to put Assert(scanrelid==0 || fdw_scan_tlist == NIL) just after
> > the GetForeignPlan() in createplan.c.
> >
> > I'm curious why you tried to put valid fdw_scan_tlist for scanrelid > 0.
> > It's unusual.
> 
> Allowing that was part of the point of Tom Lane's commit
> 1a8a4e5cde2b7755e11bde2ea7897bd650622d3e.  See the second bullet
> point, after the comma.
>
Indeed, this commit allows ForeignScan to have fdw_scan_tlist, even if
scanrelid > 0, however, I'm uncertain about its reason/intention.
Does it a preparation for the upcoming target-list-pushdown??

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


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: ALTER TABLE .. ADD PRIMARY KEY .. USING INDEX has dump-restore hazard
Next
From: Fabrízio de Royes Mello
Date:
Subject: Re: Add CINE for ALTER TABLE ... ADD COLUMN