From: | Don Seiler <don(at)seiler(dot)us> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | vacuumdb --all Parallel Feature Request |
Date: | 2018-02-15 19:30:20 |
Message-ID: | CAHJZqBAmgfhQ=79nsCGOEUESRrM+scQ-jbJ=2YA6K4kNi3NqbA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Good afternoon folks.
I've been playing around with some vacuumdb options this week as part of
post-upgrade testing, in particular with parallel (--jobs=N). I noticed
that vacuumdb --all will only work on one database at a time. This means
that as it winds down to the last few tables in a particular database,
workers will be idle. For example, I ran with 8 jobs, but while 1 job runs
on the last big table of a particular database, the other 7 are doing
nothing.
It would be great if those idle jobs would be able to move on to the next
database to get a head start on the tables there. When you have big tables
in multiple databases in the cluster, it can make a big difference.
Also, running analyze_new_cluster.sh mentions this:
If you would like default statistics as quickly as possible, cancel
> this script and run:
> "/usr/pgsql-9.6/bin/vacuumdb" --all --analyze-only
I wonder if it wouldn't be a bad idea to also mention the --jobs=N
parameter option in that blurb. Yes it's in the --help text but it wouldn't
be bad to highlight its availability.
Don.
--
Don Seiler
www.seiler.us
From | Date | Subject | |
---|---|---|---|
Next Message | hmidi slim | 2018-02-15 21:43:59 | query's performance |
Previous Message | Paul Jungwirth | 2018-02-15 19:08:43 | Re: Trigger (or something similar) on table rename? |