Re: Join push-down support for foreign tables

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>
Cc: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Join push-down support for foreign tables
Date: 2015-03-16 12:51:16
Message-ID: CA+TgmobRWtufEmsd7hTknFJXqbscCcwaKT4F5ZzQeGZaLNngng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 4, 2015 at 4:26 AM, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com> wrote:
> Here is v4 patch of Join push-down support for foreign tables. This
> patch requires Custom/Foreign join patch v7 posted by Kaigai-san.

Hi,

I just want to point out to the folks on this thread that the action
in this area is happening on the other thread, about the
custom/foreign join patch, and that Tom and I are suspecting that we
do not have the right design here. Your input is needed.

From my end, I am quite skeptical about the way
postgresGetForeignJoinPath in this patch works. It looks only at the
cheapest total path of the relations to be joined, which seems like it
could easily be wrong. What about some other path that is more
expensive but provides a convenient sort order? What about something
like A LEFT JOIN (B JOIN C ON B.x = C.x) ON A.y = B.y AND A.z = C.z,
which can't make a legal join until level 3? Tom's proposed hook
placement would instead invoke the FDW once per joinrel, passing root
and the joinrel. Then, you could cost a path based on the idea of
pushing that join entirely to the remote side, or exit without doing
anything if pushdown is not feasible.

Please read the other thread and then respond either there or here
with thoughts on that design. If you don't provide some input on
this, both of these patches are going to get rejected as lacking
consensus, and we'll move on to other things. I'd really rather not
ship yet another release without this important feature, but that's
where we're heading if we can't talk this through.

Thanks,

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-03-16 13:02:12 Re: Reduce pinning in btree indexes
Previous Message Kevin Grittner 2015-03-16 12:48:34 Re: Reduce pinning in btree indexes