Horton
Menu

Re: Custom Scan APIs (Re: Custom Plan node)

Kohei KaiGai <kaigai@kaigai.gr.jp>

View thread
From: Kohei KaiGai <kaigai@kaigai.gr.jp>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>, Kouhei Kaigai <kaigai@ak.jp.nec.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Shigeru Hanada <shigeru.hanada@gmail.com>, Jim Mlodgenski <jimmy76@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, PgHacker <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter_e@gmx.net>
Date: 2014-03-02T02:36:23Z
Lists: 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>

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.