Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs) - Mailing list pgsql-hackers

From Kouhei Kaigai
Subject Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)
Date
Msg-id 9A28C8860F777E439AA12E8AEA7694F8010EE5C8@BPXM15GP.gisp.nec.co.jp
Whole thread Raw
In response to Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
> > One thing tricky is "peusdo projection" which is done by
> > deparseProjectionSql for whole-row reference.  This is done by put the
> > query string in FROM subquery and add whole-row reference in outer
> > SELECT clause.  This is done by ExecProjection in 9.4 and older, but
> > we need to do this in postgres_fdw because ExecProjection is not
> > called any more.
> 
> What commit changed this?
>
It seems to me the nature of whole-row reference, not a flaw of
ExecProject().

In case of base relation scan, whole-row reference is transformed
to ExecEvalWholeRowVar, then executed during ExecProject().
It constructs a record datum according to the TupleDesc of the
relation being in scan.
On the other hands, foreign-join also looks like a scan on relation
that is result set of remote join, its record type is defined in
the fdw_scan_tlist.
However, it may contain values come from multiple relations,
so it is not intended behavior if whole-row reference constructs
a record datum that contains all the attributes in the result-
set. In this context, whole-row reference shall contain all the
attributes of the "base" relation.
Only FDW driver can know, and ensure all the attributes to
construct whole-row reference are fetched from remote side.

Hanada-san, could you correct me, if I misunderstood above your
explanation?

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: pg_upgrade cleanup
Next
From: Etsuro Fujita
Date:
Subject: Re: Minor improvements to alter_foreign_table.sgml