Re: changing MyDatabaseId
От | Andres Freund |
---|---|
Тема | Re: changing MyDatabaseId |
Дата | |
Msg-id | 201011171138.35938.andres@anarazel.de обсуждение исходный текст |
Ответ на | Re: changing MyDatabaseId (Markus Wanner <markus@bluegap.ch>) |
Ответы |
Re: changing MyDatabaseId
|
Список | pgsql-hackers |
On Wednesday 17 November 2010 11:04:04 Markus Wanner wrote: > Robert, > > On 11/15/2010 05:39 AM, Robert Haas wrote: > > I've spent a few hours pouring over the source code with > > coarse-toothed comb, trying to figure out just exactly what might > > break if we changed MyDatabaseId after backend startup time, or in > > other words, allowed a backend to unbind from the database to which it > > was originally bound and rebind to a new one. This is related to the > > periodic conversations we've had about a built-in connection pooler, > > and/or maintaining a pool of worker threads that could be used to > > service parallel query, replication sets, etc. What follows is not > > meant to be a concrete design proposal; it's basic research that may > > lead to a proposal at some time in the future. Still, comments are > > welcome. > > Thanks a lot for doing that, saved me a couple hours (presumably more > than it cost you :-) > > > Thoughts? > > The question obviously is whether or not this is faster than just > terminating one backend and starting a new one. Which basically costs an > additional termination and re-creation of a process (i.e. fork()) > AFAICS. Or what other savings do you envision? Well, one could optimize most of the resetting away if the the old MyDatabaseId and the new one are the same - an optimization which is hardly possible with forking new backends. Also I think it could lower the impact due locking the procarray an related areas. Andres
В списке pgsql-hackers по дате отправления: