Comments on: Do Androids Count Electric Sheep with DB2 or MySQL?

By: Both iPhone 3G S and DB2 available on the same date. Coincidence? | FreeDB2.com

Fri, 19 Jun 2009 20:03:28 +0000

[…] a steady following with the Apple Mac crowd. Antonio Cangiano recently did a little micro benchmark comparing MySQL and DB2 Express-C on his Apple MacBook Pro. He also posted an open source project for TextMate bundle for DB2. If use TextMate on your Apple […]

By: Neil Lalonde

Neil Lalonde — Fri, 12 Jun 2009 02:06:16 +0000

I find it hard to believe that any Rails app would use MyISAM tables, unless the developers don’t plan to use transactions (scary!) AND they have no intention of using WHERE clauses. In which case, maybe they can replace both MySQL and DB2 with a flat file or two.

By: Mark Callaghan

Mark Callaghan — Sun, 07 Jun 2009 02:05:01 +0000

My initial reaction to this result is that it was a ‘bad benchmark’ because a significant difference was reported without explanation. And my first guess was that DB2 cached the table in the DBMS buffer cache and InnoDB did not because of different configurations.

My reaction was probably wrong and Antonio may have found an interesting result and something we need to investigate for MySQL.

Is DB2 that much more efficient than MySQL/InnoDB? Note that MyISAM is slower than InnoDB when there is anything in the WHERE clause that prevents it from using the codepath for fast count(*) queries.

When I run ‘select count(*)’ on a table with a similar size and no indexes, the query takes ~0.4 seconds which is close to the result here. Maybe DB2 is that much faster on count queries and we need to fix MySQL.

From oprofile, these are the top 4 functions:
25.0744 rec_get_offsets_func
19.3973 row_search_for_mysql
11.1162 buf_page_optimistic_get_func
10.1157 mtr_commit

By: Antonio Cangiano

Antonio Cangiano — Sat, 06 Jun 2009 17:29:55 +0000

Lonny wrote:
Were you to add indexes, and count on indexed fields rather than (*), the performance for InnoDB in MySQL goes up dramatically.

As I mentioned before, adding an index improves the results a lot for COUNT(indexed field) but it does so in a way that is proportionate to the results shown here. This means that DB2 still is several times faster than MySQL when counting records, regardless of whether an index has been defined on a column for both databases or not.

It would be nice to do a follow up post which includes indexes and a few million records, but I suspect that people would still find other reasons to complain about the outcome. So I’m not so sure it is worth the effort.

And just to clarify something once again, this post was not meant to demonstrate that DB2 is generally faster than MySQL, even if such is the case.

By: Lonny Eachus

Lonny Eachus — Sat, 06 Jun 2009 17:00:00 +0000

To be clear, what I am saying is: Yes, this was just a “micro-benchmark”, and one should not read too much into that. However, under the circumstances, this benchmark does in fact NOT show what it purports to show: that DB2 is GENERALLY faster than MySQL.

By: Leon Katsnelson

Leon Katsnelson — Sat, 06 Jun 2009 16:58:19 +0000

I am surprised and amazed how many people are saying that InnoDB is lousy at COUNT(*) so, Antonio, you should use MyISAM instead. Isn’t the point of measuring things to compare them and to identify strengths and weaknesses? So, if Antonio did a benchmark that found that MyISAM did not do subselects very well then people would cry wolf and say you should have done this with InnoDB?
I think the benchmark is right on. If you are a Ruby on Rails programmer it is helpful to know how fast your object.count method will perform with MySQL vs. DB2. Majority of RoR programmers use MySQL and object.count is a common operation.

By: Lonny Eachus

Lonny Eachus — Sat, 06 Jun 2009 16:52:24 +0000

Yes, but you still didn’t address the point. The way your queries were performed acted precisely on the LEAST efficient operation you possibly could have chosen for MySQL. Regardless of whether it was done on purpose, it does skew the results.

Were you to add indexes, and count on indexed fields rather than (*), the performance for InnoDB in MySQL goes up dramatically. In one case, where I had a huge database (millions of records), the difference was between a full 10 minutes using count (*) and only a couple of seconds using count (indexed column).

Perhaps DB2 would outperform MySQL anyway, but, unintentional as it may be, this was still not a valid comparison. It is rather like racing a Ford sports car against a Chevy sports car, when the gas pedal on the Chevy has a block underneath that only lets the pedal go part way down.

By: Antonio Cangiano

Antonio Cangiano — Sat, 06 Jun 2009 14:59:25 +0000

Guys, I just want to clarify a few points. InnoDB was used because it’s the default – and most widely adopted – engine in the Rails community. You may notice that an id column was added for ActiveRecord, and that I only used 4 columns from the initial dataset for the sake of simplicity. To keep things simple, I used the default limits which are provided by ActiveRecord (e.g., varchar(255)). This is a simple, micro-benchmark which doesn’t need to prove much. It simply shows that with this data, under these conditions, DB2 is much faster than MySQL.

The reasons for choosing DB2 over MySQL are many, and they are not all related to performance. And even when considering performance alone, this post didn’t set out to prove that DB2 is faster than MySQL in general. There are industry benchmarks that cost millions of dollars to run that take into account all the possible moving parts. You can’t expect that from a simple post. I observed some data under particular circumstances and reported the outcome. While it is undisputed that DB2’s counting abilities are still faster than MySQL with the InnoDB engine, this post only claims that with this data, for the query used, DB2 was faster than MySQL. And I think that’s fair.

The “100 times repetition” freaked a few people out. I understand that. Please bear in mind though that I went for 100 iterations only after having seen somewhat comparable times obtained for the first execution of each query (i.e., n=1).

By: Justin Swanhart

Justin Swanhart — Sat, 06 Jun 2009 14:17:22 +0000

Wow. I shouldn’t read things in the middle of the night. DB2 not PG. Oops.

*slaps forehead*

By: Justin Swanhart

Justin Swanhart — Sat, 06 Jun 2009 12:08:25 +0000

I took a look at the feature, and it seems that PG will dynamically combine indexes using bitmaps. I guess this is similar to the ‘index merge’ functionality provided by MySQL.