On Fri, 10 Jan 2020 at 15:51, Sergei Kornilov <s...@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 tables in 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
v44-0002-delta_Allow-vacuum-command-to-process-indexes-in-parallel.patch
Description: Binary data
