Re: Odd system-column handling in postgres_fdw join pushdown patch - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Odd system-column handling in postgres_fdw join pushdown patch
Date
Msg-id CAFjFpRdOeGR6M98hnkhO7WeGpWHXGhxz1L+uQTq8yzgf2bPT=A@mail.gmail.com
Whole thread Raw
In response to Re: Odd system-column handling in postgres_fdw join pushdown patch  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: Odd system-column handling in postgres_fdw join pushdown patch  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers


On Tue, Mar 22, 2016 at 5:05 PM, Etsuro Fujita <fujita.etsuro@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.etsuro@lab.ntt.co.jp <mailto:fujita.etsuro@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

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Timeline following for logical slots
Next
From: Michael Paquier
Date:
Subject: Re: WIP: Upper planner pathification