On Sat, Jul 24, 2010 at 2:23 AM, Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
