RE: pg_upgrade: Pass -j down to vacuumdb - Mailing list pgsql-hackers

From Jamison, Kirk
Subject RE: pg_upgrade: Pass -j down to vacuumdb
Date
Msg-id D09B13F772D2274BB348A310EE3027C6413F1A@g01jpexmbkw24
Whole thread Raw
In response to Re: pg_upgrade: Pass -j down to vacuumdb  (Jesper Pedersen <jesper.pedersen@redhat.com>)
Responses Re: pg_upgrade: Pass -j down to vacuumdb
List pgsql-hackers
Hi Jesper,

On Friday, January 25, 2019, Jesper Pedersen <jesper.pedersen@redhat.com> 
> 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.

Yeah, I understood from the references that the parallel option use
for vacuumdb and pg_upgrade are different. I was also getting
clarification whether pg_upgrade gets to pass it down to vacuumdb.
Based from other Michael's and Peter's replies, I now understand it.

There were also helpful comments from the developers above,
pointing it to the right direction.
In addition to Peter's comment, quoting "...if you want to do this
as fast as possible, don't use this script.  That comment could be
enhanced to suggest the use of the -j option.", so I think you 
should also update the following script in create_script_for_cluster_analyze():
     fprintf(script, "echo %sIf you would like default statistics as quickly as possible, cancel%s\n",
             ECHO_QUOTE, ECHO_QUOTE);

There were also advice from Tom and Alvaro that you can incorporate
further in your next patch.

>Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> So let's have it write with a $VACUUMDB_OPTS variable, which is by 
>> default defined as empty but with a comment suggesting that maybe the 
>> user wants to add the -j option.  This way, if they have to edit it, 
>> they only have to edit the VACUUMDB_OPTS line instead of each of the 
>> two vacuumdb lines.
>
Tom Lane wrote:
>Even better, allow the script to absorb a value from the environment, so that it needn't be edited at all.

Regards,
Kirk Jamison

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: jsonpath
Next
From: David Rowley
Date:
Subject: Re: Delay locking partitions during query execution