Re: [HACKERS] Block level parallel vacuum

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Sergei Kornilov <sk(at)zsrv(dot)org>, Mahendra Singh Thalor <mahi6run(at)gmail(dot)com>
Cc: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Amit Langote <langote_amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, David Steele <david(at)pgmasters(dot)net>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Block level parallel vacuum
Date: 2020-01-10 07:50:58
Message-ID: CAA4eK1LHv438MZo-S5vb-OvN+juy+58OFiFDURpfcpLEdXh-FQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 9, 2020 at 5:31 PM Sergei Kornilov <sk(at)zsrv(dot)org> wrote:
>
> Hello
>
> I noticed that parallel vacuum uses min_parallel_index_scan_size GUC to skip small indexes but this is not mentioned in documentation for both vacuum command and GUC itself.
>

Changed documentation at both places.

> + /* Determine the number of parallel workers to launch */
> + if (lps->lvshared->for_cleanup)
> + {
> + if (lps->lvshared->first_time)
> + nworkers = lps->nindexes_parallel_cleanup +
> + lps->nindexes_parallel_condcleanup - 1;
> + else
> + nworkers = lps->nindexes_parallel_cleanup - 1;
> +
> + }
> + else
> + nworkers = lps->nindexes_parallel_bulkdel - 1;
>
> (lazy_parallel_vacuum_indexes)
> Perhaps we need to add a comment for future readers, why we reduce the number of workers by 1. Maybe this would be cleaner?
>

Adapted your suggestion.

>
> I have no more comments after reading the patches.
>

Thank you for reviewing the patch.

> 1.
> + <term><replaceable class="parameter">integer</replaceable></term>
> + <listitem>
> + <para>
> + Specifies a positive integer value passed to the selected option.
> + The <replaceable class="parameter">integer</replaceable> value can
> + also be omitted, in which case the value is decided by the command
> + based on the option used.
> + </para>
> + </listitem
>
> I think, now we are supporting zero also as a degree, so it should be
> changed from "positive integer" to "positive integer(including zero)"
>

I have replaced it with "non-negative integer .."

> 2.
> + * with parallel worker processes. Individual indexes are processed by one
> + * vacuum process. At the beginning of a lazy vacuum (at lazy_scan_heap) we
>
> I think, above sentence should be like "Each individual index is
> processed by one vacuum process." or one worker
>

Hmm, in the above sentence vacuum process refers to either a leader or
worker process, so not sure if what you are suggesting is an
improvement over current.

> 3.
> + * Lazy vacuum supports parallel execution with parallel worker processes. In
> + * a parallel lazy vacuum, we perform both index vacuuming and index cleanup
>
> Here, "index vacuuming" should be changed to "index vacuum" or "index
> cleanup" to "index cleaning"
>

Okay, changed at the place you mentioned and other places where
similar change is required.

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

Attachment Content-Type Size
v4-0001-Delete-empty-pages-in-each-pass-during-GIST-VACUUM.patch application/octet-stream 15.6 KB
v44-0001-Introduce-IndexAM-fields-for-parallel-vacuum.patch application/octet-stream 10.4 KB
v44-0002-Allow-vacuum-command-to-process-indexes-in-parallel.patch application/octet-stream 80.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2020-01-10 07:52:17 Re: pgbench - use pg logging capabilities
Previous Message Mahendra Singh Thalor 2020-01-10 06:26:37 Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema