Re: pg_upgrade: Pass -j down to vacuumdb

Поиск
Список
Период
Сортировка
От Jesper Pedersen
Тема Re: pg_upgrade: Pass -j down to vacuumdb
Дата
Msg-id 0984d497-1670-7ac0-76ac-fdf9ee5b3a1f@redhat.com
обсуждение исходный текст
Ответ на RE: pg_upgrade: Pass -j down to vacuumdb  ("Jamison, Kirk" <k.jamison@jp.fujitsu.com>)
Ответы RE: pg_upgrade: Pass -j down to vacuumdb  ("Jamison, Kirk" <k.jamison@jp.fujitsu.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Proposed refactoring of planner header files
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Proposed refactoring of planner header files