Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?

> On Wed, Jul 22, 2015 at 8:24 PM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> > 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??
>
> I guess Tom would have to comment on whether it could be used for that
> purpose. I assume that omitting columns could be interesting for some
> FDWs, if nothing else.
>
Indeed. As current postgres_fdw doing, FDW driver puts dummy NULLs
on unreferenced columns for network optimization, however, it shall
become unnecessary if we can change definition of the expected
record-type of foreign-table. Its advantage is more human readable
remote query and less CPU cycle for projection.

A dark side is, as discussed in this thread, complexity of EvalPlanQual.
RefetchForeignRow() returns a tuple based on foreign table definition,
on the other hands, whole-row var points a tuple based on fdw_scan_tlist
if exists.
An alternative host-only plan-node and relevant expression will be
constructed towards the definition of base foreign-table. So, we need to
transform the tuple to the layout based on foreign table definition if
we allow fdw_scan_tlist with scanrelid > 0.

However, I'm skeptical whether this solution is valid for long term.
Once we support to push down expensive expression in target-list to
remote side, fdw_scan_tlist will contain expression node rather than
simple Var node. In this case, it is not obvious to reproduce a tuple
according to the foreign table definition from a record based on the
fdw_scan_tlist.

So, I'm inclined to prohibit to set fdw_scan_tlist/custom_scan_tlist
for actual scan node (scanrelid > 0), at present.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>