Horton
Menu

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

Christian Convey <christian.convey@gmail.com>

View thread
From: Christian Convey <christian.convey@gmail.com>
To: pgsql-hackers@postgresql.org
Date: 2014-01-29T12:35:52Z
Lists: pgsql-hackers 
On Mon, Jan 27, 2014 at 7:14 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:

> FDW's join pushing down is one of the valuable use-cases of this interface,
> but not all. As you might know, my motivation is to implement GPU
> acceleration
> feature on top of this interface, that offers alternative way to scan or
> join
> relations or potentially sort or aggregate.
>

I'm curious how this relates to the pluggable storage idea discussed here
https://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting and here
http://www.databasesoup.com/2013/05/postgresql-new-development-priorities-2.html


I haven't seen a specific proposal about how much functionality should be
encapsulated by a pluggable storage system.  But I wonder if that would be
the best place for specialized table-scan code to end up?

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.