Re: Join push-down support for foreign tables
От | Robert Haas |
---|---|
Тема | Re: Join push-down support for foreign tables |
Дата | |
Msg-id | CA+TgmoYqU9qPsRapk28h+MCXMO3cmR1mK_4QZobAiLbAgqHp7g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Join push-down support for foreign tables (Shigeru HANADA <shigeru.hanada@gmail.com>) |
Список | pgsql-hackers |
On Sun, Sep 7, 2014 at 7:07 PM, Shigeru HANADA <shigeru.hanada@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
В списке pgsql-hackers по дате отправления: