Re: WIP: Join push-down for foreign tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: Join push-down for foreign tables
Date: 2011-11-17 15:24:44
Message-ID: 11845.1321543484@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> When the FDW recognizes it's being asked to join a ForeignJoinPath and a
> ForeignPath, or two ForeignJoinPaths, it throws away the old SQL it
> constructed to do the two-way join, and builds a new one to join all
> three tables.

It should certainly not "throw away" the old SQL --- that path could
still be chosen.

> That seems tedious, when there are a lot of tables
> involved. A FDW like the pgsql_fdw that constructs an SQL query doesn't
> need to consider pairs of joins. It could just as well build the SQL for
> the three-way join directly. I think the API needs to reflect that.

> I wonder if we should have a heuristic to not even consider doing a join
> locally, if it can be done remotely.

I think this is a bad idea. It will require major restructuring of the
planner, and sometimes it will fail to find the best plan, in return for
not much. The nature of join planning is that we investigate a lot of
dead ends.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2011-11-17 15:44:25 Re: ISN was: Core Extensions relocation
Previous Message Susanne Ebrecht 2011-11-17 15:11:57 Re: Removing postgres -f command line option