Re: [HACKERS] Block level parallel vacuum

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: [HACKERS] Block level parallel vacuum
Дата
Msg-id CA+fd4k7zgv3LLi2EAX6a3jbP2zpeJhu2Eq661mxj5AU4syoEfg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Block level parallel vacuum  (Sergei Kornilov <sk@zsrv.org>)
Ответы Re: [HACKERS] Block level parallel vacuum  (Sergei Kornilov <sk@zsrv.org>)
Список pgsql-hackers
On Sun, 1 Dec 2019 at 11:06, Sergei Kornilov <sk@zsrv.org> wrote:
>
> Hi
>
> > I think the advantage of the current approach is that once the parallel workers are launched, the leader can
processindexes that don't support parallelism.  So, both type of indexes can be processed at the same time. 
>
> In lazy_parallel_vacuum_or_cleanup_indexes I see:
>
>         /*
>          * Join as a parallel worker. The leader process alone does that in
>          * case where no workers launched.
>          */
>         if (lps->leaderparticipates || lps->pcxt->nworkers_launched == 0)
>                 vacuum_or_cleanup_indexes_worker(Irel, nindexes, stats, lps->lvshared,
>                                                                                  vacrelstats->dead_tuples);
>
>         /*
>          * Here, the indexes that had been skipped during parallel index vacuuming
>          * are remaining. If there are such indexes the leader process does vacuum
>          * or cleanup them one by one.
>          */
>         vacuum_or_cleanup_skipped_indexes(vacrelstats, Irel, nindexes, stats,
>                                                                           lps);
>
> So parallel leader will process parallel indexes first along with parallel workers and skip non-parallel ones. Only
afterend of the index list parallel leader will process non-parallel indexes one by one. In case of equal index
processingtime parallel leader will process (count of parallel indexes)/(nworkers+1) + all non-parallel, while parallel
workerswill process (count of parallel indexes)/(nworkers+1).  I am wrong here? 
>

I think I got your point. Your proposal is that it's more efficient if
we make the leader process vacuum the index that can be processed only
the leader process (i.e. indexes not supporting parallel index vacuum)
while workers are processing indexes supporting parallel index vacuum,
right? That way, we can process indexes in parallel as much as
possible. So maybe we can call vacuum_or_cleanup_skipped_indexes first
and then call vacuum_or_cleanup_indexes_worker. But I'm not sure that
there are parallel-safe remaining indexes after the leader finished
vacuum_or_cleanup_indexes_worker, as described on your proposal.

Regards,

--
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Issue about memory order on ARM
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Block level parallel vacuum