From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, Jim Mlodgenski <jimmy76(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PgHacker <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: Custom Scan APIs (Re: Custom Plan node) |
Date: | 2014-03-02 02:08:19 |
Message-ID: | 20140302020819.GJ12995@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Robert Haas (robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2014-03-02 02:36:23 | Re: Custom Scan APIs (Re: Custom Plan node) |
Previous Message | Stephen Frost | 2014-03-02 02:04:28 | Re: Custom Scan APIs (Re: Custom Plan node) |