Re: mysql-pgsql comparison - Mailing list pgsql-hackers

From Tom Lane
Subject Re: mysql-pgsql comparison
Date
Msg-id 26147.1010941763@sss.pgh.pa.us
Whole thread Raw
In response to Re: mysql-pgsql comparison  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: mysql-pgsql comparison  (Oleg Bartunov <oleg@sai.msu.su>)
Re: mysql-pgsql comparison  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> What we could do is:

> 1. Actually run the MySQL benchmark, to see what's wrong with it.  (Note
> that this is not the crashme test.)

This would be a worthwhile thing to try, just to see if it exposes any
PG weaknesses we didn't already know about.  I have run crashme in the
past (not recently though); but I've never found time for their
benchmark.

> 2. Port pgbench to MySQL.  Pgbench seems to be our daily benchmark of
> choice, so it's not unimportant to verify how it does elsewhere.

We use pgbench mainly because it happens to be sitting in contrib ;-).
I'm not convinced that it's a really good benchmark.  It certainly
emphasizes performance of only a very small part of the system.  For
example, we could make a huge improvement in pgbench results just by
fixing the repeated-index-lookups-of-dead-tuples problem that's been
discussed so often.  But I'm not sure that that problem is as bad in
the real world as it is in pgbench.

> 3. Check out the OSDB benchmark more closely.

I've been planning to take a hard look at that myself, but haven't found
the time.  If it's reasonably easy to install and run, it probably ought
to become our standard benchmarking tool.  (For anyone who wants to
take a look, OSDB lives at osdb.sourceforge.net.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: mysql-pgsql comparison
Next
From: Brent Verner
Date:
Subject: Re: Problem reloading regression database