On Tue, Mar 22, 2016 at 8:03 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote:
> On 2016/03/19 4:51, Robert Haas wrote: > >> On Thu, Mar 17, 2016 at 7:00 AM, Etsuro Fujita >> <fujita.ets...@lab.ntt.co.jp> wrote: >> >>> So, I'd like to propose: (1) when tableoids are >>> requested from the remote server, postgres_fdw sets valid values for >>> them locally, instead (core should support that?) >>> >> > Sure. >> > > and (2) when any of >>> xmins, xmaxs, cmins, and cmaxs are requested, postgres_fdw gives up >>> pushing down foreign joins. (We might be able to set appropriate values >>> for them locally the same way as for tableoids, but I'm not sure it's >>> worth complicating the code.) I think that would be probably OK, >>> because users wouldn't retrieve any such columns in practice. >>> >> > Now that seems like the wrong reaction. I mean, aren't these just >> going to be 0 or something? Refusing to push the join down seems >> strange. >> > > 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. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
