Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)
Дата
Msg-id CA+TgmoZzvSsjKftz5n9m0EALCXNqa8yxmBCoR5JypDVvQ1MuCA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Список pgsql-hackers
On Mon, Feb 8, 2016 at 5:45 AM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp> wrote:
> Maybe my explanation was not correct, but I'm saying that the targertlist of
> the above outer_plan should be set to the fdw_scan_tlist, to avoid
> misbehavior.

Yeah, I think you're right.  So in this hunk:

+       if (foreignrel->reloptkind == RELOPT_JOINREL)
+       {
+               /* For a join relation, get the conditions from
fdw_private structure */
+               remote_conds = fpinfo->remote_conds;
+               local_exprs = fpinfo->local_conds;
+
+               /* Build the list of columns to be fetched from the
foreign server. */
+               fdw_scan_tlist = build_tlist_to_deparse(foreignrel);
+       }

I think we should also be doing outer_plan->targetlist =
fdw_scan_tlist in this block, with a comment like "Ensure that the
outer plan produces the a tuple whose descriptor matches our scan
tuple slot.  This is safe because all scans and joins support
projection, so we never need to insert a Result node."   It would
probably be good to Assert(outer_plan != NULL) before doing the
assignment, too, just as a guard against future bugs.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: schema PL session variables
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: proposal: make NOTIFY list de-duplication optional