From: | Mahendra Singh Thalor <mahi6run(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(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-04 13:18:09 |
Message-ID: | CAKYtNAqY4sXPOau=NeBtsUX3UMn4cndi7_4Q9jH_MBDboaAhzQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 4 Jan 2020 at 07:12, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Jan 3, 2020 at 10:15 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > On Sun, Dec 29, 2019 at 4:23 PM Tomas Vondra
> > <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> > > IMO there's not much reason for the leader not to participate. For
> > > regular queries the leader may be doing useful stuff (essentially
> > > running the non-parallel part of the query) but AFAIK for VAUCUM
that's
> > > not the case and the worker is not doing anything.
> >
> > I agree, and said the same thing in
> >
http://postgr.es/m/CA+Tgmob7JLrngeHz6i60_TqdvE1YBcvGYVoEQ6_xvP=vN7DwGg@mail.gmail.com
> >
> > I really don't know why we have that code.
> >
>
> We have removed that code from the main patch. It is in a separate
> patch and used mainly for development testing where we want to
> debug/test the worker code.
>
Hi All,
In other thread "parallel vacuum options/syntax" [1], Amit Kapila asked
opinion about syntax for making normal vacuum to parallel. From that
thread, I can see that people are in favor of option(b) to implement. So I
tried to implement option(b) on the top of v41 patch set and implemented a
delta patch.
*How vacuum will work?*
If user gave "vacuum" or "vacuum table_name", then based on the number of
parallel supported indexes, we will launch workers.
Ex: vacuum table_name;
or vacuum (parallel) table_name; *//both are same.*
If user has requested parallel degree (1-1024), then we will launch workers
based on requested degree and parallel supported indexes.
Ex: vacuum (parallel 8) table_name;
If user don't want parallel vacuum, then he should set parallel degree as
zero.
Ex: vacuum (parallel 0) table_name;
I did some testing also and didn't find any issue after forcing normal
vacuum to parallel vacuum. All the test cases are passing and make check
world also passing.
Here, I am attaching delta patch that can be applied on the top of v41
patch set. Apart from delta patch, attaching gist index patch (v4) and all
the v41 patch set.
Please let me know your thoughts for this.
--
Thanks and Regards
Mahendra Singh Thalor
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.7 KB |
v41-0001-Introduce-IndexAM-fields-for-parallel-vacuum.patch | application/octet-stream | 10.3 KB |
v41-0003-Add-FAST-option-to-vacuum-command.patch | application/octet-stream | 9.7 KB |
v41-0004-Add-ability-to-disable-leader-participation-in-p.patch | application/octet-stream | 3.8 KB |
v41-0002-Add-a-parallel-option-to-the-VACUUM-command.patch | application/octet-stream | 77.0 KB |
delta_patch_to_make_vacuum_as_parallel.patch | application/octet-stream | 3.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2020-01-04 16:08:19 | Re: Errors when update a view with conditional-INSTEAD rules |
Previous Message | Peter Eisentraut | 2020-01-04 12:43:52 | Re: Refactor parse analysis of EXECUTE command |