Re: parallel vacuum options/syntax
От | Tomas Vondra |
---|---|
Тема | Re: parallel vacuum options/syntax |
Дата | |
Msg-id | 20200105115910.wfxxfpft4pvqxm6j@development обсуждение исходный текст |
Ответ на | Re: parallel vacuum options/syntax (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Sun, Jan 05, 2020 at 03:56:35PM +0530, Amit Kapila wrote: >> >> ... >> >> >If parallel vacuum is enabled by default, I would prefer (b) but I >> >don't think it's a good idea to accept 0 as parallel degree. If we want >> >to disable parallel vacuum we should max_parallel_maintenance_workers >> >to 0 instead. >> > >> >> IMO that just makes the interaction between vacuum options and the GUC >> even more complicated/confusing. >> > >Yeah, I am also not sure if that will be a good idea. > >> If we want to have a vacuum option to determine parallel degree, we >> should probably have a vacuum option to disable parallelism using just a >> vacuum option. I don't think 0 is too bad, and disable_parallel seems a >> bit awkward. Maybe we could use NOPARALLEL (in addition to PARALLEL n). >> That's what Oracle does, so it's not entirely without a precedent. >> > >We can go either way (using 0 for parallel to indicate disable >parallelism or by introducing a new option like NOPARALLEL). I think >initially we can avoid introducing more options and just go with >'Parallel 0' and if we find a lot of people find it inconvenient, then >we can always introduce a new option later. > I don't think starting with "parallel 0" and then maybe introducing NOPARALLEL sometime in the future is a good plan, because after adding NOPARALLEL we'd either have to remove "parallel 0" (breaking backwards compatibility unnecessarily) or supporting both approaches. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: