Re: WIP: Join push-down for foreign tables

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>
Cc: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: Join push-down for foreign tables
Date: 2011-10-10 16:42:35
Message-ID: CA+Tgmobd-j8mVM=vdJ2Ya03njeHUskpvCtusZm4VaPXzKtzE2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2011/10/10 Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>:
> (2011/10/08 1:06), Kohei KaiGai wrote:
>> What is the reason why the foreign join is not pushed down?
>> Maybe, injected Sort plan prevent the planner to consider both side of
>> relations being foreign scan owned by same server? I'm still
>> investigating the reason.
>
> Thanks for your testing.
>
> I'm not sure, but I think that Sort plan node would not be the reason
> because it's an element of merge join.  Maybe some wrong points would be
> in my join method consideration.
>
> In my assumption, ft1 and ft2 should be joined first (because such join
> has very low costs) and then that result and lt3 should be joined with
> one of local join methods, such as merge join and hash join.

This might be out of left field, but wouldn't it make more sense to
get postgresql_fdw committed first, and then add the join push-down
functionality afterwards? I mean, otherwise, we're going to be left
with a situation where we have join pushdown in core, but the only FDW
that can actually make use of it elsewhere.

--
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 Jeff Davis 2011-10-10 16:44:51 Re: Range Types - typo + NULL string constructor
Previous Message Robert Haas 2011-10-10 16:38:15 Re: patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c