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: | 4ED957F2.80305@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2011-12-02 23:04:57 | Re: Command Triggers |
Previous Message | Tom Lane | 2011-12-02 22:24:40 | Re: WIP: Join push-down for foreign tables |