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)
|
Список | 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 по дате отправления: