On Tue, Mar 26, 2002 at 11:25:48AM -0600, dman wrote:
> On Mon, Mar 25, 2002 at 04:26:16PM -0800, Petro wrote:
> | On Mon, Mar 25, 2002 at 02:44:25PM -0800, Tom Cook wrote:
> | > multi-user capabilities, or real scalability. Also PostgreSQL is a
> | What is "real" scalability? I've used Mysql on tiny machines
> | (Tadpole laptop) to dual processor x86 boxen with 2 gig of memory,
> | and 6 way Sun e4500s with 4 gig of memory. Database sizes from
> | trivial to over 150G of tables on a single machine.
> I couldn't find it recently when I googled, but a while back I read
> some articles written by someone at sourceforge. He was describing
> the comparision he did of several RDBMSes in the deployment of
> sourceforge. He found that for small dbs and light load that mysql
> yielded faster responses. However (at the time at least) its locking
> was table-level. This means that if someone is updating a row in a
> table, then no one else can read any other row in that table.
> PostgreSQL had more overhead on the small side of things, but for the
> many thousands of hits per minute SF had it performed much better.
> postgres has row-level locking. In the scenario above the users
> can still read their rows while the other user is modifying his. In
> an environment where web pages are generated from multiple queries
> that merge several tables the differences were very significant. The
> article provided much more detail, but that's mainly what I remember
> from the top of my head. Of course, as with any case study, the
> evidence is anecdotal.
Ah. I read that one as well.
The thing is, it *highly* depends on your database design, and
intended use. If your database is read more than written, this is of
(depending on the weight) minor to non-existent concern. Also
"clever" table design can get around this.
--
Share and Enjoy.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
