| From: | Harald Fuchs <use_reply_to(at)protecting(dot)net> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: prelimiary performance comparison pgsql vs mysql |
| Date: | 2005-03-14 13:50:18 |
| Message-ID: | pumzt69w11.fsf@srv.protecting.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
In article <010001c5288c$5e3b3c40$0200a8c0(at)dell8200>,
"Rick Schumeyer" <rschumeyer(at)ieee(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | go | 2005-03-14 13:52:58 | free space map settings |
| Previous Message | Michael Fuhr | 2005-03-14 13:44:05 | Re: plpython function problem workaround |