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
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 |