| 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: | Whole Thread | Raw Message | 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? |