From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com> |
Cc: | Greg Smith <gsmith(at)gregsmith(dot)com>, 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 12:37:54 |
Message-ID: | dcc563d10905290537ta431df1i7dfea26fe8850de6@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2009/5/29 Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>:
> 2009/5/29 Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>:
>
>>> 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).
>>
>> OTOH, you're always free to submit a patch.
> :P
>
> I thought that's where the difference is between postgresql and oracle
> mostly, ability to handle more transactions and better scalability .
Both Oracle and PostgreSQL have fairly heavy backend processes, and
running hundreds of them on either database is a mistake. Sure,
Oracle can handle more transactions and scales a bit better, but no
one wants to have to buy a 128 way E15K to handle the load rather than
implementing connection pooling. Show me an Oracle server with 5000
live, active connections and I'll show you a VERY large and expensive
cluster of machines.
From | Date | Subject | |
---|---|---|---|
Next Message | Grzegorz Jaśkiewicz | 2009-05-29 12:41:49 | Re: Scalability in postgres |
Previous Message | Grzegorz Jaśkiewicz | 2009-05-29 12:13:51 | Re: Scalability in postgres |