Re: [PoC] Asynchronous execution again (which is not parallel)

On Wed, Dec 16, 2015 at 4:54 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Fri, Dec 11, 2015 at 11:49 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> >> But is it important enough to be worthwhile? Maybe, maybe not. I
> >> think we should be working toward a world where the Gather is at the
> >> top of the plan tree as often as possible, in which case
> >> asynchronously kicking off a Gather node won't be that exciting any
> >> more - see notes on the "parallelism + sorting" thread where I talk
> >> about primitives that would allow massively parallel merge joins,
> >> rather than 2 or 3 way parallel. From my point of view, the case
> >> where we really need some kind of asynchronous execution solution is a
> >> ForeignScan, and in particular a ForeignScan which is the child of an
> >> Append. In that case it's obviously really useful to be able to kick
> >> off all the foreign scans and then return a tuple from whichever one
> >> coughs it up first.
> >
> > How will this be better than doing the same thing in a way we have done
> > Parallel Sequential Scan at ExecutorRun() time?
>
> I'm not sure if this is what you are asking, but I think it probably
> should be done at ExecutorRun() time, rather than a separate phase.
>

Yes, thats one thing I wanted to know, yet another point which is not
clear to me about this Async infrastructure is why the current
infrastructure
of Parallelism can't be used to achieve the Async benefits of ForeignScan?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com