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

From Robert Haas
Subject Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?
Date
Msg-id CA+TgmoZy2fBiqBN9-03ZNJ5fx7vh8pwvhpWEX1jk6j1sNk16aQ@mail.gmail.com
Whole thread Raw
In response to Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
List pgsql-hackers
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Free indexed_tlist memory explicitly within set_plan_refs()
Next
From: Jim Nasby
Date:
Subject: Re: [PROPOSAL] VACUUM Progress Checker.