Re: prelimiary performance comparison pgsql vs mysql - Mailing list pgsql-general

From Harald Fuchs
Subject Re: prelimiary performance comparison pgsql vs mysql
Date
Msg-id pumzt69w11.fsf@srv.protecting.net
Whole thread Raw
In response to prelimiary performance comparison pgsql vs mysql  ("Rick Schumeyer" <rschumeyer@ieee.org>)
List pgsql-general
In article <010001c5288c$5e3b3c40$0200a8c0@dell8200>,
"Rick Schumeyer" <rschumeyer@ieee.org> writes:

> These results are for a single process populating a table with 934k rows,
> and then performing some selects.  I also compared the effect of creating
> indexes on some of the columns.

> I have not yet done any testing of transactions, multiple concurrent
> processes, etc.

Bad.  That's where things begin to get interesting.

> I did not make any changes to the default config settings.

Bad.  On modern hardware MySQL performs quite good with its default
settings; PostgreSQL performs horribly without some tuning.

> I used pg 8.0.1 and mysql 5.0.2 alpha.

Bad.  As you noticed, MySQL 5.x is Alpha and not very stable.  I'd
suggest using MySQL 4.1.10 instead.

> I compiled pg from source, but I downloaded an binary for mysql.

Good.  Since MySQL is multithreaded, it's much harder to compile than
PostgreSQL.  The MySQL guys actually recommend using their binaries.

> select count(*) from data where fid=2 and rid=6;             count = 100
> select count(*) from data where x > 5000 and x < 5500;       count = 35986
> select count(*) from data where x > 5000 and x < 5020;       count = 1525

Bad.  These queries are exactly the sore point of PostgreSQL and
MySQL/InnoDB, whereas MySQL/MyISAM really shines.

pgsql-general by date:

Previous
From: Robin Ericsson
Date:
Subject: Re: prelimiary performance comparison pgsql vs mysql
Next
From: "Andrus"
Date:
Subject: Re: Using sequence name depending on other column