On 03.12.2011 00:24, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.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
