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
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 |