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

Re: [HACKERS] Large databases, performance

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: <hs(at)cybertec(dot)at>
Cc: <shridhar_daithankar(at)persistent(dot)co(dot)in>,<pgsql-performance(at)postgresql(dot)org>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: [HACKERS] Large databases, performance
Date: 2002-10-04 16:05:10
Message-ID: Pine.LNX.4.33.0210040958440.9386-100000@css120.ihs.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackerspgsql-performancepgsql-sql
On Thu, 3 Oct 2002, Hans-Jürgen Schönig wrote:

> In the case of concurrent transactions MySQL does not do as well due to 
> very bad locking behavious. PostgreSQL is far better because it does row 
> level locking instead of table locking.
> If you have many concurrent transactions MySQL performs some sort of 
> "self-denial-of-service". I'd choose PostgreSQL in order to make sure 
> that the database does not block.

While I'm no big fan of MySQL, I must point out that with innodb tables, 
the locking is row level, and the ability to handle parallel read / write 
is much improved.

Also, Postgresql does NOT use row level locking, it uses MVCC, which is 
"better than row level locking" as Tom puts it.

Of course, hot backup is only 2,000 Euros for an innodb table mysql, while 
hot backup for postgresql is free. :-)

That said, MySQL still doesn't handle parallel load nearly as well as 
postgresql, it's just better than it once was.

> Also: Keep in mind that PostgreSQL has a wonderful core team. MySQL is 
> built on Monty Widenius and the core team = Monty.
> Also: PostgreSQL = ANSI compilant, MySQL = Monty compliant

This is a very valid point.  The "committee" that creates and steers 
Postgresql is very much a meritocracy.  The "committee" that steers MySQL 
is Monty.  

I'm much happier knowing that every time something important needs to be 
done we have a whole cupboard full of curmudgeons arguing the fine points 
so that the "right thing" gets done.



In response to

Responses

pgsql-performance by date

Next:From: Hans-Jürgen SchönigDate: 2002-10-04 16:30:47
Subject: Re: [HACKERS] Large databases, performance
Previous:From: Josh BerkusDate: 2002-10-04 15:54:56
Subject: Re: Comparitive UPDATE speed

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-10-04 16:08:29
Subject: Re: Return of INSTEAD rules
Previous:From: Bruce MomjianDate: 2002-10-04 16:01:54
Subject: Re: numeric hierarchy again (was Re: floor function in 7.3b2)

pgsql-sql by date

Next:From: scott.marloweDate: 2002-10-04 16:08:54
Subject: Re: [SQL] arrays
Previous:From: Joe ConwayDate: 2002-10-04 15:51:42
Subject: Re: rows in order

pgsql-general by date

Next:From: Leland F. Jackson, CPADate: 2002-10-04 16:05:35
Subject: Re: is there a pure Win32 Port ?
Previous:From: M. I.Date: 2002-10-04 16:04:05
Subject: Re: Inheritance: delete parent deletes children

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