On Tue, Mar 22, 2016 at 5:05 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp>

> 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

Reply via email to