> -----Original Message-----
> From: Robert Haas [mailto:robertmhaas@gmail.com]
> Sent: Saturday, July 25, 2015 2:59 AM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Etsuro Fujita; pgsql-hackers@postgresql.org
> Subject: ##freemail## Re: [HACKERS] fdw_scan_tlist for foreign table scans breaks
> EPQ testing, doesn't it?
>
> On Thu, Jul 23, 2015 at 8:27 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> > 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.
>
> I don't think we can realistically make a decision that pushing down
> target list expressions to the remote side is forever off the table.
>
> Is the problem here that it's not *possible* for an FDW to do the
> right thing, or just that it might be difficult to code in practice?
> I'm fuzzy on why this isn't just a matter of having
> RefetchForeignRow() return a row with the correct tuple descriptor.
>
RefetchForeignRow() does not take ForeignScanState argument that
knows how remote data is represented on the local side if valid
fdw_scan_tlist is configured.
Do we have no facility to lookup ScanState object by scanrelid on
execution time, don't it?
On the other hands, I'm inclined to think FDW driver should provide
alternative whole-row reference (according to the base foreign-table
definition) if it has a valid fdw_scan_tlist
It is more suitable on join pushdown cases, because the alternative
subplan (to be executed instead of the remote query) assumes all the
EPQ tuples follows base table definitions as usual.
Is it not easy to inject a junk TLE to reference a whole-row variable
based on the foreign table definition?
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>
