From: | Don Baccus <dhogaza(at)pacifier(dot)com> |
---|---|
To: | Mark Pritchard <mark(at)tangent(dot)net(dot)au> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Connection Pooling, a year later |
Date: | 2001-12-18 16:33:53 |
Message-ID: | 3C1F6FF1.9030606@pacifier.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Pritchard wrote:
>>I think it is the startup cost that most people want to avoid, and our's
>>is higher than most db's that use threads; at least I think so.
>>
>>It would just be nice to have it done internally rather than have all
>>the clients do it, iff it can be done cleanly.
>>
>
> I'd add that client side connection pooling isn't effective in some cases
> anyway - one application we work with has 4 physical application servers
> running around 6 applications. Each of the applications was written by a
> different vendor, and thus a pool size of five gives you 120 open
> connections.
Tuning a central pooling mechanism to run well in this kind of situation
isn't going to be a trivial task, either. The next thing you'll want is
some way to prioritize the various clients so your more serious
applications have a better chance of getting a pool.
Or you'll want to set up subpools so they don't compete with each other,
in effect replicating what's done now, but adding more complexity to the
central service.
--
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org
From | Date | Subject | |
---|---|---|---|
Next Message | Brian Hirt | 2001-12-18 16:49:20 | Re: problems with table corruption continued |
Previous Message | Don Baccus | 2001-12-18 16:29:10 | Re: Connection Pooling, a year later |