2014-02-26 17:31 GMT+09:00 Kouhei Kaigai <kai...@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.


>> Heikki Linnakangas<heikki.linnakan...@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.


Shigeru HANADA

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to