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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PoC] Asynchronous execution again (which is not parallel)
Дата
Msg-id CA+TgmoZFyX3sERxE+Otg6R75Y2DZOrXPZ-qZBjwyK06fn+XOyw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PoC] Asynchronous execution again (which is not parallel)  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [PoC] Asynchronous execution again (which is not parallel)  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Fri, Dec 11, 2015 at 11:49 PM, Amit Kapila <amit.kapila16@gmail.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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: WIP: bloom filter in Hash Joins with batches
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [PATCH] Equivalence Class Filters