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

From Jesper Pedersen
Subject Re: pg_upgrade: Pass -j down to vacuumdb
Date
Msg-id 0984d497-1670-7ac0-76ac-fdf9ee5b3a1f@redhat.com
Whole thread Raw
In response to RE: pg_upgrade: Pass -j down to vacuumdb  ("Jamison, Kirk" <k.jamison@jp.fujitsu.com>)
Responses RE: pg_upgrade: Pass -j down to vacuumdb  ("Jamison, Kirk" <k.jamison@jp.fujitsu.com>)
List pgsql-hackers
Hi,

On 1/30/19 7:59 PM, Jamison, Kirk wrote:
>> I added most of the documentation back, as requested by Kirk.
> 
> Actually, I find it useful to be documented. However, major contributors have higher opinions in terms of experience,
soI think it's alright with me not to include the doc part if they finally say so.
 
> 

I think we need to leave it to the Committer to decide, as both Peter  
and Michael are committers; provided the patch reaches RfC.

>>> It seems to me that the latest patch sent is incorrect for multiple
>>> reasons:
>>> 1) You still enforce -j to use the number of jobs that the caller of
>>> pg_upgrade provides, and we agreed that both things are separate
>>> concepts upthread, no?  What has been suggested by Alvaro is to add a
>>> comment so as one can use VACUUM_OPTS with -j optionally, instead of
>>> suggesting a full-fledged vacuumdb command which depends on what
>>> pg_upgrade uses.  So there is no actual need for the if/else
>>> complication business.
> 
>> I think it is ok for the echo command to highlight to the user that running --analyze-only using the same amount of
jobswill give a faster result.
 
> 
> I missed that part.
> IIUC, using the $VACUUMDB_OPTS variable would simplify and correct the usage of jobs for vacuumdb. (pg_upgrade jobs
isnot equal to vacuumdb jobs) Plus, it might simplify and reduce the number of additional lines.
 
> Tom Lane also suggested above to make the script absorb the value from env.
> Would that address your concern of getting a faster result, yes?
> 

The actual line in the script executed is using $VACUUMDB_OPTS at the  
moment, so could you expand on the above ? The 'if' could be removed if  
we assume that pg_upgrade would only be used with server > 9.5, but to  
be safer I would leave it in, as it is only console output.

Best regards,
  Jesper


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Proposed refactoring of planner header files
Next
From: Tom Lane
Date:
Subject: Re: Proposed refactoring of planner header files