Обсуждение: MySQL/InnoDB benchmarks
OK, Probably people are sick of MySQL stuff, but I think this is worth having a squiz at. As you may be aware, InnoDB is a table handler for MySQL that adds row-level locking, transactions and foreign keys to MySQL. Note that there is NO cascade support in this implementation of foreign keys. Now, the InnoDB guys have done some benchmarks: http://www.innodb.com/bench.html However, I notice that they seem to have optimised the Postgres server adequately, and tested lots of concurrent users, and found that Postgres is basically slow and unscalable... This is for people's edification, I'm not making any further comments on the benchmarks!! Chris
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Now, the InnoDB guys have done some benchmarks:
If I did some benchmarks comparing Postgres and MySQL, and they came out
in favor of PG, I'm sure the MySQL guys would cry foul --- and with good
reason, seeing that I have no clue how to configure MySQL optimally.
But we are supposed to consider their tests to be unbiased? Get real.
What really needs to be done here is a set of tests designed and
conducted by an *impartial* third party, with advice from experts in
each camp on how to properly configure their own DB. I haven't seen
any prospects for such a thing to happen, though. In the meantime,
I put no credence in MySQL-sponsored benchmarks, and I see no reason
for us to spend time generating our own equally-not-unbiased responses.
Let's get on with our development work rather than worrying about FUD.
regards, tom lane
On Jue 21 Feb 2002 02:38, you wrote: > OK, > > Probably people are sick of MySQL stuff, but I think this is worth having a > squiz at. As you may be aware, InnoDB is a table handler for MySQL that > adds row-level locking, transactions and foreign keys to MySQL. Note that > there is NO cascade support in this implementation of foreign keys. > > Now, the InnoDB guys have done some benchmarks: > > http://www.innodb.com/bench.html I would have loved to see 100 processes simultaniously inserting 1000 records to the databases (did you check the source of the benchmark?). PostgreSQL would have kicked 'em all! Saludos... :-) -- Porqué usar una base de datos relacional cualquiera, si podés usar PostgreSQL? ----------------------------------------------------------------- Martín Marqués | mmarques@unl.edu.ar Programador, Administrador, DBA | Centro de Telematica Universidad Nacional del Litoral -----------------------------------------------------------------
Out of curiosity I ran the "benchmark" on an untuned fairly loaded single 1Ghz CPU box, my times based on their specs were (in seconds rounded up): Insert of 100 000 rows, copied from a table 3 Sum of an integer column from a join of 100 000 rows 3 Granted it's still slower than the InnoDB results and I did test against 7.2, but I'm sure with a little tweaking I could almost halve my times. I have to agree with the others, something looks awful funny about their results! However, I would add that it's all a moot point really since the benchmark doesn't even attempt to test concurrent transactions but that's probably for a reason! ;-) Cheers, Marc Christopher Kings-Lynne wrote: > OK, > > Probably people are sick of MySQL stuff, but I think this is worth having a > squiz at. As you may be aware, InnoDB is a table handler for MySQL that > adds row-level locking, transactions and foreign keys to MySQL. Note that > there is NO cascade support in this implementation of foreign keys. > > Now, the InnoDB guys have done some benchmarks: > > http://www.innodb.com/bench.html > > However, I notice that they seem to have optimised the Postgres server > adequately, and tested lots of concurrent users, and found that Postgres is > basically slow and unscalable... > > This is for people's edification, I'm not making any further comments on the > benchmarks!! > > Chris > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > >
Marc Lavergne wrote: > > Granted it's still slower than the InnoDB results and I did test against > 7.2, but I'm sure with a little tweaking I could almost halve my times. > I have to agree with the others, something looks awful funny about their > results! However, I would add that it's all a moot point really since > the benchmark doesn't even attempt to test concurrent transactions but > that's probably for a reason! ;-) All they have shown so far is that they can read our mailing lists. The SMP problems in 7.1.1 are well known, yawn. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
On Thu, 2002-02-21 at 11:00, Tom Lane wrote: > "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > > Now, the InnoDB guys have done some benchmarks: > > If I did some benchmarks comparing Postgres and MySQL, and they came out > in favor of PG, I'm sure the MySQL guys would cry foul --- and with good > reason, seeing that I have no clue how to configure MySQL optimally. > But we are supposed to consider their tests to be unbiased? Get real. Still they show the theoretical possibility of speeding up these two features: INSERT INTO ... SELECT FROM - seems we have still room for improving btree inserts - I did the same tests with my desktop pc (RH7.1, PG 7.2, default conf) and got 4.83sec with primary key on T2 and 1.17 without. INSERT + CREATE UNIQUE INDEX took 4.56 sec. SELECT SUM(T1.B) FROM T1, T2 WHERE T1.A = T2.B - Most likely InnoDB can do this from index only for T2. I guess it would be possible for PG to at least cache tmin and tmax for index tuples in memory, if not on disk. > What really needs to be done here is a set of tests designed and > conducted by an *impartial* third party, with advice from experts in > each camp on how to properly configure their own DB. I haven't seen > any prospects for such a thing to happen, though. In the meantime, > I put no credence in MySQL-sponsored benchmarks, and I see no reason > for us to spend time generating our own equally-not-unbiased responses. It could be educating to run something simple like pgbench on both. -------------- Hannu