Re: Postgres_fdw join pushdown - wrong results with whole-row reference

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgres_fdw join pushdown - wrong results with whole-row reference
Date: 2016-06-24 08:38:20
Message-ID: CAFjFpRda0kMDX6+V7ojBhNMhft=rYEF3j=fKQXXevbo-7Ot8Fg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 24, 2016 at 1:59 PM, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp
> wrote:

> On 2016/06/24 15:44, Ashutosh Bapat wrote:
> >>
> >> I think the proposed idea of applying record::text explicit coercion to
> a
> >> whole-row reference in the IS NOT NULL condition in the CASE WHEN
> >> conversion would work as expected as you explained, but I'm concerned
> that
> >> the cost wouldn't be negligible when the foreign table has a lot of
> columns.
> >
> > That's right, if the foreign server doesn't optimize the case for IS NOT
> > NULL, which it doesn't :)
> >
> > I am happy to use any cheaper means e.g a function which counts number of
> > columns in a record. All we need here is a way to correctly identify
> when a
> > record is null and not null in the way we want (as described upthread). I
> > didn't find any quickly. Do you have any suggestions?
>
> I'm now starting to wonder if it would be outright wrong to just use the
> alias names of corresponding foreign tables directly for whole-row
> references? So, instead of these in target lists of remote queries:
>
> SELECT CASE WHEN (r1.*)::text IS NOT NULL THEN *ROW (r1.*)* END, ...
>
>
This is wrong. The deparsed query looks like
SELECT CASE WHEN (r1.*)::text IS NOT NULL THEN *ROW (r1.col1, r1.col2, ...)*
END,

The reason for this is that the foreign table definition may not match the
target table definition. This has been explained in the comments that you
have deleted in your patch. Am I missing something?

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-06-24 08:46:16 Re: primary_conninfo missing from pg_stat_wal_receiver
Previous Message Amit Langote 2016-06-24 08:29:48 Re: Postgres_fdw join pushdown - wrong results with whole-row reference