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

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

In response to

Browse pgsql-hackers by date

  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)