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:08:19Z
Lists: pgsql-hackers 
* Robert Haas (robertmhaas@gmail.com) wrote:
> For what it's worth, and I can't claim to have all the answers here,
> this doesn't match my expectation.  I think we'll do two kinds of
> parallelism.  One will be parallelism within nodes, like parallel sort
> or parallel seqscan.  Any node we parallelize this way is likely to be
> heavily rewritten, or else to get a sister that looks quite different
> from the original.  

Sure.

> The other kind of parallelism will involve pushing
> a whole subtree of the plan into a different node.  In this case we'll
> need to pass data between nodes in some different way (this was one of
> the major reasons I designed the shm_mq stuff) but the nodes
> themselves should change little if at all.

It's that "some different way" of passing data between the nodes that
makes me worry, but I hope you're right and we won't actually need to
change the interfaces or the nodes very much.

	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.