Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL a slow DB?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christopher Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: PostgreSQL a slow DB?
Date: 2006-04-17 14:53:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-novice
Christopher Browne <cbbrowne(at)acm(dot)org> writes:
> Traditionally, MySQL(tm) has had a lot of loosely-done, unanalyzed
> "benchmarketing" done where the tests done are those that can be done
> without any real design.  MySQL(tm) probably still has some advantages in
> performance when the usage patterns combine:
>  a) Single user access
>  b) A series of simple queries expected to access one or two tuples
>  c) Low system load
>  d) A pattern that discourages transaction usage
> Any "designed in 15 minutes" sort of benchmark is quite likely to fit
> into this.

FWIW, the last time I tried Postgres on the "benchmark" test suite that
comes with MySQL, PG was about half the speed of MySQL overall.  Now
MySQL AB have obviously spent a lot more than 15 minutes on mysql-bench,
but it answers the rest of Chris' description pretty well.

The other little problem with mysql-bench is that it's *by design*
biased to overweight things that MySQL is particularly fast at, and
underweight things it's not.  I'm not certain the MySQL guys even
consciously recognize that, but think about how it works: practically
all of the tests involve repeating some-trivial-operation N number of
times.  That would be fine, except they choose different numbers N for
different tests, apparently with the goal of making sure each test takes
about the same total time when run on MySQL.  For example, let's assume
that query A takes 1 second and query B takes 10 seconds on MySQL, but
vice versa on Postgres.  If these were in mysql-bench, the benchmark
would be set up to run A say 100 times and B 10 times, making each
component of the benchmark run for 100 sec on MySQL.  Total score: 200
sec.  PG comes along and runs A*100 in 1000 sec and B*10 in 10 sec, for
a total score of 1010 sec.  Obviously PG sucks, right?  No, it's the
methodology.  And that doesn't even consider the fact that the benchmark
suite simply doesn't test anything you can't do at all in MySQL.

I think a lot of the "PG is slow" buzz you hear on the net is from
people who have been misled by mysql-bench and other poorly designed

Now, if the actual use you intend to put the database to matches the
single-client, lots-of-very-simple-queries model, then by all means you
should take a hard look at MySQL.  But if you've got concurrent clients
or complicated queries, you had better do your own benchmarking.  BTW,
don't forget that when the MySQL fanboys say "we're fast AND we've got
transactions", they usually omit to mention "(but not at the same
time)".  MySQL isn't really one database, it's three or four different
ones depending on which storage engine you use.  And they've got
different feature sets and performance profiles.  Be real wary about
extrapolating results with one storage engine to another one.  (I'm
pretty sure that mysql-bench tests only MyISAM.)

			regards, tom lane

In response to


pgsql-novice by date

Next:From: Vincent FrisonDate: 2006-04-17 15:20:33
Subject: Re: Renaming unnamed FK constraints
Previous:From: RelaxinDate: 2006-04-17 14:39:11
Subject: Re: PostgreSQL a slow DB?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group