RE: pg_upgrade: Pass -j down to vacuumdb

From: "Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>
To: "'jesper(dot)pedersen(at)redhat(dot)com'" <jesper(dot)pedersen(at)redhat(dot)com>, "Peter Eisentraut" <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>
Subject: RE: pg_upgrade: Pass -j down to vacuumdb
Date: 2019-01-25 02:31:57
Message-ID: D09B13F772D2274BB348A310EE3027C64137E4@g01jpexmbkw24
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


According to CF app, this patch needs review so I took a look at it.
Currently, your patch applies and builds cleanly, and all tests are also successful
based from the CF bot patch tester.

I'm not sure if I have understood the argument raised by Peter correctly.
Quoting Peter, "it's not clear that pg_upgrade and vacuumdb are bound the same way, so it's not a given that the same -j number should be used."
I think it's whether the # jobs for pg_upgrade is used the same way for parallel vacuum.

According to the official docs, the recommended setting for pg_upgrade --j option is the maximum of the number of CPU cores and tablespaces. [1]
As for vacuumdb, parallel vacuum's (-j) recommended setting is based from your max_connections [2], which is the max # of concurrent connections to your db server.


Kirk Jamison

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2019-01-25 02:50:03 Re: WIP: Avoid creation of the free space map for small tables
Previous Message Corey Huinker 2019-01-25 01:37:48 Re: \describe*