Skip site navigation (1) Skip section navigation (2)

Re: Scalability in postgres

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: (view raw, whole thread or download thread mbox)
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.

In response to


pgsql-performance by date

Next:From: Grzegorz JaśkiewiczDate: 2009-05-29 12:41:49
Subject: Re: Scalability in postgres
Previous:From: Grzegorz JaśkiewiczDate: 2009-05-29 12:13:51
Subject: Re: Scalability in postgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group