Re: [HACKERS] Block level parallel vacuum - Mailing list pgsql-hackers

From Sergei Kornilov
Subject Re: [HACKERS] Block level parallel vacuum
Date
Msg-id 1962511575194802@sas8-7ec005b03c91.qloud-c.yandex.net
Whole thread Raw
In response to Re: [HACKERS] Block level parallel vacuum  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] Block level parallel vacuum  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
List pgsql-hackers
Hi

> I think the advantage of the current approach is that once the parallel workers are launched, the leader can process
indexesthat 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?
 

regards, Sergei



pgsql-hackers by date:

Previous
From: "盏一"
Date:
Subject: Issue about memory order on ARM
Next
From: Grigory Smolkin
Date:
Subject: Re: pg_upgrade fails with non-standard ACL