Re: Parallel Seq Scan

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Parallel Seq Scan
Дата
Msg-id CAA4eK1KXQjGUC1CbqE6ouC28PvMzvs1Qx0aZTxJHqmcF-O3c0w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Fri, Oct 16, 2015 at 9:51 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, Oct 5, 2015 at 8:20 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > [ new patch for heapam.c changes ]
>
> There's a second patch attached here as well, parallel-relaunch.patch,
> which makes it possible to relaunch workers with the same parallel
> context.  Currently, after you WaitForParallelWorkersToFinish(), you
> must proceed without fail to DestroyParallelContext().  With this
> rather simple patch, you have the option to instead go back and again
> LaunchParallelWorkers(), which is nice because it avoids the overhead
> of setting up a new DSM and filling it with all of your transaction
> state a second time.  I'd like to commit this as well, and I think we
> should revise execParallel.c to use it.
>

I have rebased the partial seq scan patch based on the above committed
patches.  Now for rescanning it reuses the dsm and to achieve that we
need to ensure that workers have been completely shutdown and then
reinitializes the dsm.  To ensure complete shutdown of workers, current
function  WaitForParallelWorkersToFinish is not sufficient as that just
waits for the last message to receive from worker backend, so I have
written a new function WaitForParallelWorkersToDie.  Also on receiving
'X' message in HandleParallelMessage, it just frees the worker handle
without ensuring if the worker is died due to which later it will be difficult
to even find whether worker is died or not, so I have removed that code
from HandleParallelMessage.  Another change is that after receiving last
tuple in Gather node, it just shutdown down the workers without
destroying the dsm.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Вложения

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

Предыдущее
От: Kouhei Kaigai
Дата:
Сообщение: Re: Foreign join pushdown vs EvalPlanQual
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [RFC] overflow checks optimized away