On Sat, Jul 24, 2010 at 2:23 AM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
> On 24/07/10 01:28, Robert Haas wrote:
>
>> Well, if we could change the backends so that they could fully
>> reinitialize themselves (disconnect from a database to which they are
>> bound, etc.), I don't see why we couldn't use the Apache approach.
>
> This would offer the bonus on the side that it'd be more practical to
> implement database changes for a connection, akin to MySQL's "USE".
> Inefficient, sure, but possible.
Yep.
> I don't care about that current limitation very much. I think anyone
> changing databases all the time probably has the wrong design and should
> be using schema. I'm sure there are times it'd be good to be able to
> switch databases on one connection, though.
I pretty much agree with this. I think this is merely slightly nice
on its own, but I think it might be a building-block to other things
that we might want to do down the road. Markus Wanner's Postgres-R
replication uses worker processes; autovacuum does as well; and then
there's parallel query. I can't help thinking that not needing to
fork a new backend every time you want to connect to a new database
has got to be useful.
> My question with all this remains: is it worth the effort when external
> poolers already solve the problem.
Whether it's worth the effort is something anyone who is thinking
about working on this will have to decide for themselves.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company