Skip site navigation (1) Skip section navigation (2)

Re: Pooling in Core WAS: Need help in performance tuning.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
Date: 2010-07-25 22:09:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Sat, Jul 24, 2010 at 2:23 AM, Craig Ringer
<craig(at)postnewspapers(dot)com(dot)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.


> 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
The Enterprise Postgres Company

In response to

pgsql-performance by date

Next:From: Piotr GasidłoDate: 2010-07-26 08:35:43
Subject: Big difference in time returned by EXPLAIN ANALYZE SELECT ... AND SELECT ...
Previous:From: Yeb HavingaDate: 2010-07-25 19:13:16
Subject: Re: Testing Sandforce SSD

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group