> On Wed, Jul 22, 2015 at 8:24 PM, Kouhei Kaigai <kai...@ak.jp.nec.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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
