From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Samuel Gendler <sgendler(at)ideasculptor(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Need help in performance tuning. |
Date: | 2010-07-09 20:35:28 |
Message-ID: | AANLkTimegmfnQ59MB0xM8H_zCesCgQJvVJby6E_5vOWt@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, Jul 9, 2010 at 12:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Samuel Gendler <sgendler(at)ideasculptor(dot)com> writes:
>> On Thu, Jul 8, 2010 at 8:11 PM, Craig Ringer
>> <craig(at)postnewspapers(dot)com(dot)au> wrote:
>>> If you're not using a connection pool, start using one.
>
>> I see this issue and subsequent advice cross this list awfully
>> frequently. Is there in architectural reason why postgres itself
>> cannot pool incoming connections in order to eliminate the requirement
>> for an external pool?
>
> Perhaps not, but there's no obvious benefit either. Since there's
> More Than One Way To Do It, it seems more practical to keep that as a
> separate problem that can be solved by a choice of add-on packages.
I'm not buying it. A separate connection pooler increases overhead
and management complexity, and, I believe, limits our ability to
implement optimizations like parallel query execution. I'm glad there
are good ones available, but the fact that they're absolutely
necessary for good performance in some environments is not a feature.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Palmer | 2010-07-09 22:36:15 | Index usage with functions in where condition |
Previous Message | Robert Haas | 2010-07-09 20:25:30 | Re: Slow query with planner row strange estimation |