Re: pgsql: Allow vacuum command to process indexes in parallel. - Mailing list pgsql-committers

From Amit Kapila
Subject Re: pgsql: Allow vacuum command to process indexes in parallel.
Date
Msg-id CAA4eK1JQeNtsBA0-mdi-bAzejpbjRNC6BmJY6KBRqkkPeCU+Qg@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Allow vacuum command to process indexes in parallel.  (Andres Freund <andres@anarazel.de>)
Responses Re: pgsql: Allow vacuum command to process indexes in parallel.  (Mahendra Singh Thalor <mahi6run@gmail.com>)
List pgsql-committers
On Mon, Mar 30, 2020 at 4:18 AM Andres Freund <andres@anarazel.de> wrote:
>
> 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?
>

I'll look into it.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Cosmetic improvements in ltree code.
Next
From: Amit Kapila
Date:
Subject: pgsql: Introduce vacuum errcontext to display additional information.