| From: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com> |
|---|---|
| To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
| Cc: | Flavio Henrique Araque Gurgel <flavio(at)4linux(dot)com(dot)br>, Fabrix <fabrixio1(at)gmail(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Scalability in postgres |
| Date: | 2009-05-29 10:45:02 |
| Message-ID: | 2f4958ff0905290345p56625f6fsef719f134559a7a0@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Fri, May 29, 2009 at 2:54 AM, Greg Smith <gsmith(at)gregsmith(dot)com> wrote:
> The PostgreSQL connection handler is known to be bad at handling high
> connection loads compared to the popular pooling projects, so you really
> shouldn't throw this problem at it. While kernel problems stack on top of
> that, you really shouldn't start at kernel fixes; nail the really
> fundamental and obvious problem first.
if it is implemented somewhere else better, shouldn't that make it
obvious that postgresql should solve it internally ? It is really
annoying to hear all the time that you should add additional path of
execution to already complex stack, and rely on more code to handle
something (poolers).
--
GJ
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2009-05-29 12:10:44 | Re: Scalability in postgres |
| Previous Message | Greg Smith | 2009-05-29 01:54:52 | Re: Scalability in postgres |