Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)
От | Kouhei Kaigai |
---|---|
Тема | Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs) |
Дата | |
Msg-id | 9A28C8860F777E439AA12E8AEA7694F8010EE5C8@BPXM15GP.gisp.nec.co.jp обсуждение исходный текст |
Ответ на | Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs) (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: