I was just reading up on the syntax for index hints in MySQL, and noticed this:

An index_name value need not be a full index name. It can be an unambiguous prefix of an index name. If a prefix is ambiguous, an error occurs.

I actually prefer not to have extra “syntactic sugar” features such as this. It helps avoid bugs and unexpected behavior. Even if I don’t use it intentionally, I can get bitten by it, if someone adds another index whose name has the same prefix as one that I already use:

mysql> create table t(a int primary key);
mysql> select * from t force index(PRIMAR);
Empty set (0.00 sec)

mysql> alter table t add key PRIMARY_2(a);

mysql> select * from t force index(PRIMAR);
ERROR 1176 (HY000): Key 'PRIMAR' doesn't exist in table 't'

I actually considered adding support for prefixes of …

Most database companies would be proud to say that their products perform optimally out of the box. It means they accomplished a Herculean feat of engineering. But most databases have configuration options because this is almost impossible. For example, MySQL has scores of tuning options, and it needs a lot more.

So when someone benchmarks your database and makes you look bad, usually you can say “that benchmark was run by someone who doesn’t know how to properly tune my database software.”

But what if the benchmarker claims that your database didn’t need to be tuned, (via Dave Page), because it’s optimal out of the box? Do you accept the benchmark results, or reject the compliment?

Related posts:

…

have now written and pushed ndbapi testing of our push-down join implementation (~2k LOC)

the following classes/programs was added

• HugoQueryBuilder (class)
  Construct a pseudo-random query
  inputs: a list of tables and a options specifying which features should be used in query
• HugoQueries (class)
  Run an arbitrary query.
  Note: Does only verify individual rows, not relations/result-set. For verifying result-sets we use random query generator
• testSpj (program)
  Ndbapi test-program using above classes to runs various tests for our cluster specific automatic testing framework
• hugoJoin (program)
  Stand-alone test-program that takes list of tables/options as command-line arguments
  and using above classes constructs/runs random queries

Quite happy with this, as it's very much needed to get good …

A few years ago, during the MySQL Conference opening keynote, two world maps of MySQL downloads were displayed. With the lights down, they made an impression.
Oddly enough, to the best of my knowledge, the downloads map has not been drawn again since then. I asked my friend and colleague Markus Popp, and he provided the data from the downloads logs, leaving the implementation to me.
A first attempt with Google Maps API produced a chart that is nice to see for a single country or town, but hardly pleasant for the entire world.

Then, I abandoned the easy path, and looked at CPAN for inspiration, and immediately found something that could solve my problem. Using …

Last month while being at the MySQL Conference, several people asked me about the status of BlitzDB. Specifically, they were interested in when I’ll release BlitzDB. Fair enough – I’ve been working on this project long enough for people to start questioning this.

The answer is, BlitzDB is done in terms of implementing the design. Right now it’s about finding bugs, fixing it and testing BlitzDB’s stability under concurrent load. Thanks to the motivation boost I gained at the conference, I’ve now fixed the bugs that were slowing me down and I’m gradually adding more tests into BlitzDB’s test suite. I consider BlitzDB’s initial release to be the day it gets merged into Drizzle’s trunk. This is almost ready as BlitzDB seems to be building fine on Drizzle’s Build Farm infrastructure. However, I won’t move to the next step until I’m satisfied with BlitzDB’s stability.

Yesterday I spent some time doing some …

I have to admit that FlashCache for Linux looks pretty cool.

It basically lets you use a block device SSD as cache.

Another hack is to mount the SSD as swap and tell InnoDB to use say 100GB of memory. I haven’t tested this but it might be a fun hack :)

We’ve actually migrated away from using SSD in production – at least for now.

The performance just wasn’t THAT great in our configuration. I’m still semi optimistic but not as much as I was a year ago.

I think if I were to do it again I would drop RAID everywhere with SSD and make sure my database layer can correctly route queries to the right MySQL instance.

Each SSD would need to be on its own database server with its own replication thread. …

Jeremy moved the emt svn repository to google code last night. This gives it better integration with the issues tracker, google’s kick ass source browser and gives me the ability to add more commit rights without giving people accounts on servers. Check out the new source tab. Especially the part that lists the field objects. EMT ships without about 100 metrics not counting dynamic sub fields including checks for mysql, apache, memcache, per process memory, network, and other system stats.

I was just reading up on the syntax for index hints in MySQL, and noticed this: An index_name value need not be a full index name. It can be an unambiguous prefix of an index name. If a prefix is ambiguous, an error occurs. I actually prefer not to have extra “syntactic sugar” features such as this. It helps avoid bugs and unexpected behavior. Even if I don’t use it intentionally, I can get bitten by it, if someone adds another index whose name has the same prefix as one that I already use:

Most database companies would be proud to say that their products perform optimally out of the box. It means they accomplished a Herculean feat of engineering. But most databases have configuration options because this is almost impossible. For example, MySQL has scores of tuning options, and it needs a lot more. So when someone benchmarks your database and makes you look bad, usually you can say “that benchmark was run by someone who doesn’t know how to properly tune my database software.

Recently I rewrote the whole internal grid editing stuff to have bidirectional record sets. Means, editing grid data is no longer restricted to the Data tab. Any Query tab now allows you to edit your row data - at least if it's a simple query without joins and if it contains sufficient key columns. This was one of the most wanted features by users, described in issue #723.

As a side effect, query results are client-sortable now. When you click a column header, the grid itself is just sorted. This is surely not a replacement for having an ORDER BY clause in your query, but helps a lot to work quicker with simple grid results. Note that the Data tab works different here - the SELECT query is reposted with an adjusted ORDER BY clause. Only for the query tabs this is not possible as the query is totally user edited, no internal …