| 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 |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
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.
[1] https://www.postgresql.org/docs/current/pgupgrade.html
[2] https://www.postgresql.org/docs/current/app-vacuumdb.html
Regards,
Kirk Jamison
| 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* |