On Sun, Sep 7, 2014 at 7:07 PM, Shigeru HANADA <shigeru.han...@gmail.com> wrote: >> I think it's probably good to give an FDW the option of producing a >> ForeignJoinPath for any join against a ForeignPath *or >> ForeignJoinPath* for the same FDW. It's perhaps unlikely that an FDW >> can perform a join efficiently between two data sources with different >> server definitions, but why not give it the option? It should be >> pretty fast for the FDW to realize, oh, the server OIDs don't match - >> and at that point it can exit without doing anything further if that >> seems desirable. And there might be some kinds of data sources where >> cross-server joins actually can be executed quickly (e.g. when the >> underlying data is just in two files in different places on the local >> machine). > > Indeed how to separate servers is left to users, or author of FDWs, though > postgres_fdw and most of other FDWs can join foreign tables in a server. I > think it would be good if we can know two foreign tables are managed by same > FDW, from FdwRoutine, maybe adding new API which returns FDW identifier?
Do we need this? I mean, if you get the FdwRoutine, don't you have the OID of the FDW or the foreign table also? > I think so too, so ForeignJoinPath should be able to be an input of another > ForeignJoinPath in upper join level. But I also think joining on remote or > not should be decided based on cost, as existing joins are planned with > bottom-up approach. Definitely. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
