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 reaches RfC.
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
