2014-02-26 17:31 GMT+09:00 Kouhei Kaigai <kaigai@ak.jp.nec.com>:
> IIUC, his approach was integration of join-pushdown within FDW APIs,
> however, it does not mean the idea of remote-join is rejected.
> I believe it is still one of our killer feature if we can revise the
> implementation.
>
> Hanada-san, could you put the reason why your proposition was rejected
> before?
IIUC it was not rejected, just returned-with-feedback. We could not
get consensus about how join-push-down works. A duscussion point was
multiple paths for a joinrel, but it was not so serious point. Here
is the tail of the thread.
http://www.postgresql.org/message-id/4F058241.2000606@enterprisedb.com
>> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes:
>>>
>>> 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.
>>
>>
>> ... or ordered vs unordered, etc. Yeah, good point, we already got this
>> wrong with the PlanForeignScan API. Good thing we didn't promise that
>> would be stable.
>
>
> This discussion withered down here...
>
> I think the advice to Shigeru-san is to work on the API. We didn't reach a
> consensus on what exactly it should look like, but at least you need to be
> able to return multiple paths for a single joinrel, and should look at
> fixing the PlanForeignScan API to allow that too.
And I've gave up for lack of time, IOW to finish more fundamental
portion of FDW API.
http://www.postgresql.org/message-id/4F39FC1A.7090202@gmail.com
--
Shigeru HANADA
