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

From Etsuro Fujita
Subject Odd system-column handling in postgres_fdw join pushdown patch
Date
Msg-id 56EA8E56.2050306@lab.ntt.co.jp
Whole thread Raw
Responses Re: Odd system-column handling in postgres_fdw join pushdown patch
Re: Odd system-column handling in postgres_fdw join pushdown patch
List pgsql-hackers
Hi,

I noticed that the postgres_fdw join pushdown patch retrieves system
columns other than ctid (and oid) from the remote server as shown in the
example:

postgres=# explain verbose select foo.tableoid, foo.xmin, foo.cmin,
foo.xmax, foo.cmax, foo.* from foo, bar where foo.a = bar.a;

   QUERY PLAN


--------------------------------------------------------------------------------------------------------------------------------------------------------
--------
 Foreign Scan  (cost=100.00..102.09 rows=2 width=28)
   Output: foo.tableoid, foo.xmin, foo.cmin, foo.xmax, foo.cmax, foo.a,
foo.b
   Relations: (public.foo) INNER JOIN (public.bar)
   Remote SQL: SELECT r1.tableoid, r1.xmin, r1.cmin, r1.xmax, r1.cmax,
r1.a, r1.b FROM (public.foo r1 INNER JOIN public.bar r2 ON (TRUE)) WHERE
((r1.a =
 r2.a))
(4 rows)

BUT: we don't make any effort to ensure that local and remote values
match, so system columns other than ctid and oid should not be retrieved
from the remote server.  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?) 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.

Attached is a proposed patch for that.

Best regards,
Etsuro Fujita

Attachment

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: btree_gin and btree_gist for enums
Next
From: Artur Zakirov
Date:
Subject: Re: Proposal: Generic WAL logical messages