Message-ID: <01c601c26bc4$73d5f900$4201a8c0@beeblebrox>
From: "Michael Paesold" <mpaesold@gmx.at>
To: <pgsql-performance@postgresql.org>
References: <3D9C8712.9513.9C6521D@localhost>
	<3D9CBAD7.23509.A908C61@localhost> <3D9C7579.2010206@cybertec.at>
	<20021003170920.X18497@mail.libertyrms.com>
Subject: Re: Large databases, performance
Date: Fri, 4 Oct 2002 18:38:21 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Andrew Sullivan <andrew@libertyrms.info> wrote:

> On Thu, Oct 03, 2002 at 06:51:05PM +0200, 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.
>
> It is my understanding that MySQL no longer does this on InnoDB
> tables.  Whether various bag-on-the-side table types are a good thing
> I will leave to others; but there's no reason to go 'round making
> claims about old versions of MySQL any more than there is a reason to
> continue to talk about PostgreSQL not being crash safe.  MySQL has
> moved along nearly as quickly as PostgreSQL.

Locking and transactions is not fine in MySQL (with InnoDB) though. I tried
to do selects on a table I was concurrently inserting to. In a single thread
I was constantly inserting 1000 rows per transaction. While inserting I did
some random selects on the same table. It often happend that the insert
transactions were aborted due to dead lock problems. There I see the problem
with locking reads.
I like PostgreSQL's MVCC!

Regards,
Michael Paesold