| From: | Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Need help in performance tuning. |
| Date: | 2010-07-09 12:56:25 |
| Message-ID: | 1278680186.1914.36.camel@bnicholson-desktop |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Fri, 2010-07-09 at 00:42 -0400, Tom Lane 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.
This sounds similar to the approach to taken with Replication for years
before being moved into core.
Just like replication, pooling has different approaches. I do think
that in both cases, having a solution that works, easily, out of the
"box" will meet the needs of most users.
There is also the issue of perception/adoption here as well. One of my
colleagues mentioned that at PG East that he repeatedly heard people
talking (negatively) about the over reliance on add-on packages to deal
with core DB functionality.
--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2010-07-09 15:09:53 | Re: Need help in performance tuning. |
| Previous Message | damien hostin | 2010-07-09 10:13:27 | Re: Slow query with planner row strange estimation |