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