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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
