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

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [PoC] Asynchronous execution again (which is not parallel)
Дата
Msg-id CAA4eK1+h50ojHdGxaP5aoWgbZ+iwi21z1bN0MaNeLjBSFoO_=A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PoC] Asynchronous execution again (which is not parallel)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [PoC] Asynchronous execution again (which is not parallel)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Wed, Dec 16, 2015 at 4:54 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> 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.
>

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

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: "pg_upgrade" cannot write to log file pg_upgrade_internal.log
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pgbench stats per script & other stuff