Re: PostgreSQL a slow DB? - Mailing list pgsql-novice
From | Tom Lane |
---|---|
Subject | Re: PostgreSQL a slow DB? |
Date | |
Msg-id | 835.1145285599@sss.pgh.pa.us Whole thread Raw |
In response to | Re: PostgreSQL a slow DB? (Christopher Browne <cbbrowne@acm.org>) |
Responses |
Re: PostgreSQL a slow DB?
|
List | pgsql-novice |
Christopher Browne <cbbrowne@acm.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 benchmarks. 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
pgsql-novice by date: