Horton
Menu

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

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Kouhei Kaigai <kaigai@ak.jp.nec.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Kohei KaiGai <kaigai@kaigai.gr.jp>, 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-02T01:38:12Z
Lists: pgsql-hackers 
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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.