On Tue, Mar 22, 2016 at 5:05 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote:
> On 2016/03/22 14:54, Ashutosh Bapat wrote: > >> On Tue, Mar 22, 2016 at 8:03 AM, Etsuro Fujita >> <fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote: >> OK, I'll modify the patch so that the join is pushed down even if >> any of xmins, xmaxs, cmins, and cmaxs are requested. Do you think >> which one should set values for these as well as tableoids, >> postgres_fdw or core? >> > > Earlier in this mail chain, I suggested that the core should take care >> of storing the values for these columns. But instead, I think, core >> should provide functions which can be used by FDWs, if they want, to >> return values for those columns. Something like Datum >> get_syscol_value(RelOptInfo/Relation, attno). The function will return >> Datum 0 for most of the columns and table's OID for tableoid. My 0.02. >> > > What I had in mind was (1) create_foreignscan_plan would create Lists from > the ForeignScan's fdw_scan_tlist: (a) indexes/OID values of tableoids in > fdw_scan_tlist, and (b) indexes of xids and cids in fdw_scan_tlist, and > then (2) ForeignNext would set the OID values for the tableoid columns in > the scan tuple, using the Lists (a), and appropriate values (0 or > something) for the xid and cid columns in the scan tuple, using the List > (b). > Looks Ok to me, although, that way an FDW looses an ability to use its own values for those columns, in case it wants to. For example, while using postgres_fdw for sharding, it might help saving xmax, xmin, cmax, cmin from the foreign server and use them while communicating with the foreign server. > > Best regards, > Etsuro Fujita > > > -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
