Re: Writable foreign tables: how to identify rows

2013/3/6 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Also, the right way to deal with this desire is to teach the planner in
> general, not just FDWs, about pushing expensive calculations down the
> plan tree --- basically, resurrecting Joe Hellerstein's thesis work,
> which we ripped out more than ten years ago. I don't think there's that
> much that would need to change about the planner's data structures, but
> deciding where is cheapest to evaluate an expression is a pretty hard
> problem. Trying to handle that locally within FDWs is doomed to failure
> IMO.
>
It also seems to me more attractive direction to support a mechanism
to off-load calculation of expensive expression in general, not only
foreign-tables.

Probably, we have to include the cost to compute expression node to
choose a proper plan node. For example, if an extension injected
a pseudo scan node to materialize underlying regular table and
calculate target entry using SIMD operations, its cost to compute
target-entry shall be 25% towards regular ones. So, planner shall
choose this plan-node in case of advantage.

> So my intention is to get rid of GetForeignRelWidth() and make use of
> the existing ctid system column for returning remote TIDs in
> postgres_fdw. (On review I notice that we're creating ctid columns
> for foreign tables already, so we don't even need the proposed hook
> to let FDWs control that; though we will certainly want one in future
> if we are to support non-TID magic row identifiers.)
>
OK. It gets back to the initial implementation that uses TID system column.
I'll try to adjust my patches by the next week.

Probably, we should allow FDW drivers to specify data type of TID system
column in future development, rather than new system columns, because
the non-TID magic row-identifier is used exclusively with TID.

> If you find that unacceptable, I'm quite willing to mark this patch
> Returned With Feedback and get on with dealing with some of the other
> forty-odd patches in the CF queue.
>
A bird is a reasonable outcome with a stone, even though it is not two birds.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>