Re: Custom Scan APIs (Re: Custom Plan node)
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Kohei KaiGai <kaigai@kaigai.gr.jp>
Cc: Kouhei Kaigai <kaigai@ak.jp.nec.com>,
Shigeru Hanada <shigeru.hanada@gmail.com>,
Jim Mlodgenski <jimmy76@gmail.com>,
Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
PgHacker <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter_e@gmx.net>
Date: 2014-03-01T13:38:17Z
Lists: pgsql-hackers
KaiGai, * Kohei KaiGai (kaigai@kaigai.gr.jp) wrote: > BTW, this kind of discussion looks like a talk with a ghost because > we cannot see the new interface according to the parallel execution > right now, so we cannot have tangible investigation whether it becomes > really serious backward incompatibility, or not. Yeah, it would certainly be nice if we had all of the answers up-front. What I keep hoping for is that someone who has been working on this area (eg: Robert) would speak up... > My bet is minor one. I cannot imagine plan-node interface that does > not support existing non-parallel SeqScan or NestLoop and so on. Sure you can- because once we change the interface, we're probably going to go through and make everything use the new one rather than have to special-case things. That's more-or-less exactly my point here because having an external hook like CustomScan would make that kind of wholesale change more difficult. That does *not* mean I'm against using GPUs and GPU optimizations. What it means is that I'd rather see that done in core, which would allow us to simply change that interface along with the rest when doing wholesale changes and not have to worry about backwards compatibility and breaking other people's code. Thanks, Stephen
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
- 784e762e886e 9.4.0 cited