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 CAFjFpRfdng=tunaDzLjt+npw50Vu3z5As6HJakw0UbAuqwZ-sw@mail.gmail.com
Whole thread Raw
In response to Re: Odd system-column handling in postgres_fdw join pushdown patch  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers


On Fri, Apr 15, 2016 at 10:17 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Apr 15, 2016 at 12:16 PM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
> The testcases had tableoid::regclass which outputs the foreign table's local
> name, which won't change across runs. Isn't that so?

[rhaas pgsql]$ grep 16444 ~/Downloads/postgres-fdw-syscol-zap-ab.patch
+         Remote SQL: SELECT r1.c1, CASE WHEN r1.* IS NOT NULL THEN 0
END, CASE WHEN r1.* IS NOT NULL THEN 0 END, CASE WHEN r1.* IS NOT NULL
THEN 0 END, CASE WHEN r1.* IS NOT NULL THEN 16444 END, CASE WHEN r2.*
IS NOT NULL THEN 0 END, CASE WHEN r2.* IS NOT NULL THEN 16447 END,
r2.c1 FROM ("S 1"."T 3" r1 INNER JOIN "S 1"."T 4" r2 ON (TRUE)) WHERE
((r1.c1 = r2.c1)) ORDER BY r1.c1 ASC NULLS LAST
+         Remote SQL: SELECT r1.c1, CASE WHEN r1.* IS NOT NULL THEN
16444 END, CASE WHEN r2.* IS NOT NULL THEN 16447 END, r2.c1 FROM ("S
1"."T 3" r1 LEFT JOIN "S 1"."T 4" r2 ON (((r1.c1 = r2.c1)))) ORDER BY
r1.c1 ASC NULLS LAST, r2.c1 ASC NULLS LAST
+         Remote SQL: SELECT r1.c1, CASE WHEN r1.* IS NOT NULL THEN
16444 END, CASE WHEN r2.* IS NOT NULL THEN 16447 END, r2.c1 FROM ("S
1"."T 3" r1 FULL JOIN "S 1"."T 4" r2 ON (((r1.c1 = r2.c1)))) ORDER BY
r1.c1 ASC NULLS LAST, r2.c1 ASC NULLS LAST

Where do you think 16444 and 16447 are coming from here?

Ah! Sorry, it's the explain output.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Odd system-column handling in postgres_fdw join pushdown patch
Next
From: Robert Haas
Date:
Subject: Re: Declarative partitioning