Re: pg_upgrade: Pass -j down to vacuumdb

From: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>
To: "Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>
Cc: 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>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: pg_upgrade: Pass -j down to vacuumdb
Date: 2019-01-25 13:30:57
Message-ID: c448acf6-7c38-3d6d-c663-5387ccffb906@redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Kirk,

On 1/24/19 9:31 PM, Jamison, Kirk wrote:
> 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.
>

Thanks for your feedback !

As per Peter's comments I have changed the patch (v2) to not pass down
the -j option to vacuumdb.

Only an update to the documentation and console output is made in order
to make it more clear.

Best regards,
Jesper

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-01-25 14:01:01 Re: House style for DocBook documentation?
Previous Message Daniel Verite 2019-01-25 13:16:22 Re: Alternative to \copy in psql modelled after \g