2013/3/6 Tom Lane <t...@sss.pgh.pa.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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
