Re: WIP: Join push-down for foreign tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: Join push-down for foreign tables
Date
Msg-id 11845.1321543484@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: Join push-down for foreign tables  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: WIP: Join push-down for foreign tables  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.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


pgsql-hackers by date:

Previous
From: Susanne Ebrecht
Date:
Subject: Re: Removing postgres -f command line option
Next
From: Peter Geoghegan
Date:
Subject: Re: ISN was: Core Extensions relocation