Horton
Menu

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

Stephen Frost <sfrost@snowman.net>

View thread
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Kouhei Kaigai <kaigai@ak.jp.nec.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-02T02:04:28Z
Lists: pgsql-hackers 
* Robert Haas (robertmhaas@gmail.com) wrote:
> I don't see that parallelizing Append is any easier than any other
> problem in this space.  There's no parallel I/O facility, so you need
> a background worker per append branch to wait on I/O.  And you have
> all the problems of making sure that the workers have the same
> snapshot, making sure they don't self-deadlock, etc. that you have for
> any other case.

Erm, my thought was to use a select() loop which sends out I/O requests
and then loops around waiting to see who finishes it.  It doesn't
parallelize the CPU cost of getting the rows back to the caller, but
it'd at least parallelize the I/O, and if what's underneath is actually
a remote FDW running a complex query (because the other side is actually
a view), it would be a massive win to have all the remote FDWs executing
concurrently instead of serially as we have today.

	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 →

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