From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PoC] Asynchronous execution again (which is not parallel) |
Date: | 2015-12-12 04:49:22 |
Message-ID: | CAA4eK1+T2hHU7cCF1hOOP0sxK1zXysja_5aJ_m=U6SUB_M8bZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 8, 2015 at 9:10 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Mon, Nov 30, 2015 at 7:47 AM, Kyotaro HORIGUCHI
> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> 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?
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2015-12-12 08:10:18 | Re: Using quicksort for every external sort run |
Previous Message | Mark Dilger | 2015-12-12 04:43:12 | Re: Bootstrap DATA is a pita |