Re: Odd system-column handling in postgres_fdw join pushdown patch

On Tue, Mar 22, 2016 at 5:05 PM, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
wrote:

> On 2016/03/22 14:54, Ashutosh Bapat wrote:
>
>> On Tue, Mar 22, 2016 at 8:03 AM, Etsuro Fujita
>> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp <mailto:fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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