Re: Rename max_parallel_degree?
От | Robert Haas |
---|---|
Тема | Re: Rename max_parallel_degree? |
Дата | |
Msg-id | CA+Tgmoahd_j_T4MMzezMjB2=FZCig36MBYjWEz=+2UaKsOsyUA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Rename max_parallel_degree? (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: Rename max_parallel_degree?
Re: Rename max_parallel_degree? |
Список | pgsql-hackers |
On Wed, Oct 12, 2016 at 8:13 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 10/4/16 10:16 AM, Julien Rouhaud wrote: >> Please find attached v9 of the patch, adding the parallel worker class >> and changing max_worker_processes default to 16 and max_parallel_workers >> to 8. I also added Amit's explanation for the need of a write barrier >> in ForgetBackgroundWorker(). > > This approach totally messes up the decoupling between the background > worker facilities and consumers of those facilities. Having dozens of > lines of code in bgworker.c that does the accounting and resource > checking on behalf of parallel.c looks very suspicious. Once we add > logical replication workers or whatever, we'll be tempted to add even > more stuff in there and it will become a mess. I attach a new version of the patch that I've been hacking on in my "spare time", which reduces the footprint in bgworker.c quite a bit. I don't think it's wrong that the handling is done there, though. The process that is registering the background worker is well-placed to check whether there are already too many, and if it does not then the slot is consumed at least temporarily even if it busts the cap. On the flip side, the postmaster is the only process that is well-placed to know when a background worker terminates. The worker process itself can't be made responsible for it, as you suggest below, because it may never even start up in the first place (e.g. fork() returns EAGAIN). And the registering process can't be made responsible, because it might die before the worker. > I think we should think of a way where we can pass the required > information during background worker setup, like a pointer to the > resource-limiting GUC variable. I don't think this can work, per the above. > For style, I would also prefer the "class" to be a separate struct field > from the flags. I think that it makes sense to keep the class as part of the flags because then a large amount of the stuff in this patch that is concerned with propagating the flags around becomes unnecessary. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: