On Sat, Jul 24, 2010 at 2:23 AM, Craig Ringer
> 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.
> 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.
The Enterprise Postgres Company
In response to
pgsql-performance by date
|Next:||From: Piotr Gasidło||Date: 2010-07-26 08:35:43|
|Subject: Big difference in time returned by EXPLAIN ANALYZE SELECT ... AND SELECT ...|
|Previous:||From: Yeb Havinga||Date: 2010-07-25 19:13:16|
|Subject: Re: Testing Sandforce SSD|