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: AANLkTin9gE2=UGJBT04RyTWeMaALr48-vQnCce7zt=W1@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

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

In response to

Browse pgsql-performance by date

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