Skip site navigation (1) Skip section navigation (2)

Re: WIP: Join push-down for foreign tables

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-12-02 22:57:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 03.12.2011 00:24, Tom Lane wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com>  writes:
>> On 02.12.2011 18:55, Tom Lane wrote:
>>> Furthermore, you seem to be imagining that there is only one best path
>>> for any join, which isn't the case.
>> No, I understand that the planner considers many alternatives, even at
>> the same time, because of different output sort orders and startup vs.
>> total cost. I'm imagining that the planner would ask the FDW to
>> construct the two-way joins, and consider joining the results of those
>> locally to the third table, and also ask the FDW to construct the
>> three-way join as whole. And then choose the cheapest alternative.
> It probably makes sense to turn control over to the FDW just once to
> consider all possible foreign join types for a given join pair, ie
> we don't want to ask it separately about nestloop, hash, merge joins.
> But then we had better be able to let it generate multiple paths within
> the one call, and dump them all to add_path.  You're still assuming that
> there is one unique best path for any join, and *that is not the case*,
> or at least we don't know which will be the best at the time we're
> generating join paths.  We don't know whether fast-start is better than
> cheapest-total, nor which sort order might be the best, until we get up
> to the highest join level.

Hmm, so you're saying that the FDW function needs to be able to return 
multiple paths for a single joinrel. Fair enough, and that's not 
specific to remote joins. Even a single-table foreign scan could be 
implemented differently depending on whether you prefer fast-start or 
cheapest total.

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2011-12-02 23:04:57
Subject: Re: Command Triggers
Previous:From: Tom LaneDate: 2011-12-02 22:24:40
Subject: Re: WIP: Join push-down for foreign tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group