RE: pg_upgrade: Pass -j down to vacuumdb
От | Jamison, Kirk |
---|---|
Тема | RE: pg_upgrade: Pass -j down to vacuumdb |
Дата | |
Msg-id | D09B13F772D2274BB348A310EE3027C6416F6E@g01jpexmbkw24 обсуждение исходный текст |
Ответ на | Re: pg_upgrade: Pass -j down to vacuumdb (Jesper Pedersen <jesper.pedersen@redhat.com>) |
Ответы |
Re: pg_upgrade: Pass -j down to vacuumdb
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: