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
