Re: Custom Scan APIs (Re: Custom Plan node)
От | Kohei KaiGai |
---|---|
Тема | Re: Custom Scan APIs (Re: Custom Plan node) |
Дата | |
Msg-id | CADyhKSWqmjZHXff7pr2fZk_AcWqJGFJ0BVnZJL5Tg9F__Ou3vA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Custom Scan APIs (Re: Custom Plan node) (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
2014-03-02 10:38 GMT+09:00 Robert Haas <robertmhaas@gmail.com>: > On Wed, Feb 26, 2014 at 10:23 AM, Stephen Frost <sfrost@snowman.net> wrote: >> * Kouhei Kaigai (kaigai@ak.jp.nec.com) wrote: >>> IIUC, his approach was integration of join-pushdown within FDW APIs, >>> however, it does not mean the idea of remote-join is rejected. >> >> For my part, trying to consider doing remote joins *without* going >> through FDWs is just nonsensical. > > That is, of course, true by definition, but I think it's putting the > focus in the wrong place. It's possible that there are other cases > when a scan might a plausible path for a joinrel even if there are no > foreign tables in play. For example, you could cache the joinrel > output and then inject a cache scan as a path for the joinrel. > That might be an idea to demonstrate usage of custom-scan node, rather than the (ad-hoc) enhancement of postgres_fdw. As I have discussed in another thread, it is available to switch heap reference by cache reference on the fly, it shall be a possible use- case for custom-scan node. So, I'm inclined to drop the portion for postgres_fdw in my submission to focus on custom-scan capability. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: