Re: [HACKERS] Large databases, performance

Поиск
Список
Период
Сортировка
От scott.marlowe
Тема Re: [HACKERS] Large databases, performance
Дата
Msg-id Pine.LNX.4.33.0210040958440.9386-100000@css120.ihs.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Large databases, performance  (Hans-Jürgen Schönig <postgres@cybertec.at>)
Список pgsql-general
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.



В списке pgsql-general по дате отправления:

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: Inheritance: delete parent deletes children
Следующее
От: "scott.marlowe"
Дата:
Сообщение: Re: [SQL] arrays