Re: pgsql: Allow vacuum command to process indexes in parallel. - Mailing list pgsql-committers
From | Andres Freund |
---|---|
Subject | Re: pgsql: Allow vacuum command to process indexes in parallel. |
Date | |
Msg-id | 20200329224818.6phnhv7o2q2rfovf@alap3.anarazel.de Whole thread Raw |
In response to | pgsql: Allow vacuum command to process indexes in parallel. (Amit Kapila <akapila@postgresql.org>) |
Responses |
Re: pgsql: Allow vacuum command to process indexes in parallel.
Re: pgsql: Allow vacuum command to process indexes in parallel. |
List | pgsql-committers |
Hi, On 2020-01-20 02:33:34 +0000, Amit Kapila wrote: > Allow vacuum command to process indexes in parallel. > > This feature allows the vacuum to leverage multiple CPUs in order to > process indexes. This enables us to perform index vacuuming and index > cleanup with background workers. This adds a PARALLEL option to VACUUM > command where the user can specify the number of workers that can be used > to perform the command which is limited by the number of indexes on a > table. Specifying zero as a number of workers will disable parallelism. > This option can't be used with the FULL option. > > Each index is processed by at most one vacuum process. Therefore parallel > vacuum can be used when the table has at least two indexes. > > The parallel degree is either specified by the user or determined based on > the number of indexes that the table has, and further limited by > max_parallel_maintenance_workers. The index can participate in parallel > vacuum iff it's size is greater than min_parallel_index_scan_size. > > Author: Masahiko Sawada and Amit Kapila > Reviewed-by: Dilip Kumar, Amit Kapila, Robert Haas, Tomas Vondra, > Mahendra Singh and Sergei Kornilov > Tested-by: Mahendra Singh and Prabhat Sahu > Discussion: > https://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com > https://postgr.es/m/CAA4eK1J-VoR9gzS5E75pcD-OH0mEyCdp8RihcwKrcuw7J-Q0+w@mail.gmail.com Coverity is complaining that: > ** CID ...: Incorrect expression (UNINTENDED_INTEGER_DIVISION) > /srv/coverity/git/pgsql-git/postgresql/src/backend/commands/vacuum.c: 2078 in compute_parallel_delay() > > > ________________________________________________________________________________________________________ > *** CID ...: Incorrect expression (UNINTENDED_INTEGER_DIVISION) > /srv/coverity/git/pgsql-git/postgresql/src/backend/commands/vacuum.c: 2078 in compute_parallel_delay() > 2072 shared_balance = pg_atomic_add_fetch_u32(VacuumSharedCostBalance, VacuumCostBalance); > 2073 > 2074 /* Compute the total local balance for the current worker */ > 2075 VacuumCostBalanceLocal += VacuumCostBalance; > 2076 > 2077 if ((shared_balance >= VacuumCostLimit) && > >>> CID ...: Incorrect expression (UNINTENDED_INTEGER_DIVISION) > >>> Dividing integer expressions "VacuumCostLimit" and "nworkers", and then converting the integer quotient to type"double". Any remainder, or fractional part of the quotient, is ignored. > 2078 (VacuumCostBalanceLocal > 0.5 * (VacuumCostLimit / nworkers))) > 2079 { > 2080 /* Compute sleep time based on the local cost balance */ > 2081 msec = VacuumCostDelay * VacuumCostBalanceLocal / VacuumCostLimit; > 2082 pg_atomic_sub_fetch_u32(VacuumSharedCostBalance, VacuumCostBalanceLocal); > 2083 VacuumCostBalanceLocal = 0; Which seems like a fair enough complaint? Greetings, Andres Freund
pgsql-committers by date: