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. http://www.postgresql.org/message-id/4f058241.2000...@enterprisedb.com >> 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. http://www.postgresql.org/message-id/4f39fc1a.7090...@gmail.com -- Shigeru HANADA -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
