On January 31, 2019, 9:29PM +0000, Jesper Pedersen 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,so I 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
reachesRfC.
Agreed.
>>> 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 jobs will give a faster result.
Since you used user_opts.jobs (which is coming from pg_upgrade, is it not?),
could you clarify more the statement above? Or did you mean somehow that
it won't be a problem for vacuumdb to use the same?
Though correctness-wise is arguable, if the committers can let it pass
from your answer, then I think it's alright.
I'm not sure if misunderstood the purpose of $VACUUMDB_OPTS. I thought what
the other developers suggested is to utilize it so that --jobs for vacuumdb
would be optional and just based from user-specified option $VACUUMDB_OPTS.
By which it would not utilize the amount of jobs used for pg_upgrade.
To address your need of needing a parallel, the script would just then
suggest if the user wants a --jobs option. The if/else for number of jobs is
not needed in that case, maybe only for ifndef WIN32 else case.
Regards,
Kirk Jamison