Re: [HACKERS] Block level parallel vacuum
| От | Mahendra Singh Thalor |
|---|---|
| Тема | Re: [HACKERS] Block level parallel vacuum |
| Дата | |
| Msg-id | CAKYtNAroXD9C5bAiqne1KZV0vpEhfKZqbinH4AW9pDV_V9KYgQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Block level parallel vacuum (Sergei Kornilov <sk@zsrv.org>) |
| Ответы |
Re: [HACKERS] Block level parallel vacuum
Re: [HACKERS] Block level parallel vacuum |
| Список | pgsql-hackers |
On Fri, 10 Jan 2020 at 15:51, Sergei Kornilov <sk@zsrv.org> wrote:
>
> Hi
> Thank you for update! I looked again
>
> (vacuum_indexes_leader)
> + /* Skip the indexes that can be processed by parallel workers */
> + if (!skip_index)
> + continue;
>
> Does the variable name skip_index not confuse here? Maybe rename to something like can_parallel?
I also agree with your point.
>
> Another question about behavior on temporary tables. Use case: the user commands just "vacuum;" to vacuum entire
database(and has enough maintenance workers). Vacuum starts fine in parallel, but on first temporary table we hit:
>
> + if (RelationUsesLocalBuffers(onerel) && params->nworkers >= 0)
> + {
> + ereport(WARNING,
> + (errmsg("disabling parallel option of vacuum on \"%s\" --- cannot vacuum temporary
tablesin parallel",
> + RelationGetRelationName(onerel))));
> + params->nworkers = -1;
> + }
>
> And therefore we turn off the parallel vacuum for the remaining tables... Can we improve this case?
Good point.
Yes, we should improve this. I tried to fix this. Attaching a delta
patch that is fixing both the comments.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: