Category Archives: Rants

Enough with the circling

The police helicopter that has been circling for an hour is driving me crazy. Every night, they circle around in San Jose with their search light. Who are they looking for? I’m sure if they let us know, someone would give them up in order to make the constant “whiiiiiiiirrrrrrr zeeeeeee whuuuuurrrrr” stop. This totally ruins the windows-open-all-the-time spring/summer experience.

Madness continues: SHOW STATUS

Last month I blogged about the silly changes to the default for the SHOW STATUS command in MySQL 5.0 in Stop the madness: SHOW STATUS, and I filed MySQL Bug #19093: SHOW STATUS defaults to SESSION.

Well, it looks like Monty has spoken and this will not be fixed. That’s unfortunate, but oh well, I tried.

You can read the full text of Monty’s reply in the bug report itself, but his reasons for supporting the current behaviour boil down to:

  • It’s similar to what SHOW VARIABLES does. — Yes, this is true, but neither commands’ output makes sense, really. If you do SHOW [SESSION] STATUS, you get a mix of session-scoped and global-scoped results back, and there’s no way to tell which is which. Same goes for SHOW [SESSION] VARIABLES. Ugh.
  • MySQL 5.0 is considered “stable” now, so it’s bad to change it now. — I agree on this part, it’s bad form to change it now, but at the same time, very few people are really using 5.0, so this is in fact a good time to change it, before people find out that it’s broken.
  • MySQL’s documentation has long suggested that people use FLUSH STATUS and SHOW STATUS to find out how query was executed, which kind of works now. — Yes, the manual has suggested this, and a few people have made limited use of it, but come on, it’s impossible to use this in production, and it’s only even of limited value on a test server.

I suggested a compromise: To add a Scope column to the output of the SHOW STATUS and SHOW VARIABLES commands, which would indicate the scope of the value seen in the output. What do you think?

Stop the madness: SHOW STATUS

Are you a MySQL user? Have you tried 5.0? Did you notice that SHOW STATUS was giving you strange results?

Here’s the skinny: The SHOW STATUS command, which has been in MySQL, well forever, has had a long-standing feature request; to have the ability to report its metrics per-session. That functionality was added in MySQL 5.0, in the form of two new syntaxes: SHOW SESSION STATUS and SHOW GLOBAL STATUS to give the per-session and server-wide statistics, respectively. It’s great, and I’m happy to see it.

The problem comes in because of the default behaviour that was chosen for the basic SHOW STATUS with no SESSION or GLOBAL keyword—that is, the command that every MySQL DBA has been using for years—now defaults to per-session statistics.

Every tool, program, monitoring script, performance graph, etc., that uses SHOW STATUS (which is pretty much all of them) is broken in 5.0. Why? Well, for no reason, in my opinion. There is absolutely no advantage to defaulting to per-session statistics instead of the old standard of global statistics.

If you’re upset about this, add your comment to MySQL Bug #19093 and fight the good fight with me.

DHL: Clueless?

I recently signed up with Vonage, since it seems pretty cool. They sent me the VoIP adapter via DHL, who picked it up on Thursday, April 6th. It was sent 2nd day delivery, which means it should have been delivered on Monday, April 10th. Did I get it? Nope!

All through yesterday, April 10th, the DHL website claimed:

Est. Delivery Date: 4/10/2006

Today, Tuesday, April 11th, I figured I’d give them a call to see what’s up, and when I should expect to really receive the package, since the site still claims that the estimated delivery date is yesterday, which doesn’t inspire much confidence. The conversation went something like this:

DHL: Thanks for calling DHL, what can I help you with?
Me: I was sent a package which was supposed to be delivered yesterday, but I haven’t received it. I tracked the package on your website, and it still claims an estimated delivery date of yesterday, which can’t be right.
DHL: OK, can you give me the tracking number?
Me: OK, (reads tracking number)…
DHL: Well, we have a lot of packages and not all of them go out every day etc. etc. … your package is here at the sorting facility, it hasn’t gone out today.
Me: Uh, well, it was sent 2nd day delivery, the 2nd day was yesterday. Should I at least expect to receive it today?
DHL: Well, I can’t really tell you that. I don’t know if it will go out today, it’s still here… I don’t know if you’ll get it today.
Me: Don’t you have some sort of service guarantee, or the shipping is free?
DHL: Uh, uh, I don’t know, you’d have to talk to billing about that, I don’t know anything about that…

What the hell? You are DHL. Your only real business is moving other people’s stuff around. How is this considered customer service?

MySQL 5.0: Remarkably Painful

MySQL 5.0 has a ton of new features. In fact, several tons. Many people and companies were waiting endlessly for some of these features. Some of the new features include: Views, Stored Procedures and Stored Functions, Triggers, and some extra optimizations. Hoorah.

However, not all is peaches. In fact, there are few peaches to be found. Consider the rest of this post a bitch/complaint session and a call for a return to sanity. Let’s take a look at some of the major features of MySQL 5.0:

Views — Views are a great idea. Overall, they even work great. Their biggest downfall is that their MERGE algorithm doesn’t work with UNION, which means that the view engine falls back to the TEMPTABLE algorithm instead. That means it completely forms the view: running the full UNION, dumping the results into a temporary table, and then applying the view against that temporary table. What that really means is that views are useless for replacing MyISAM merge tables, which means we still have no way to do the same thing with InnoDB.

Stored Procedures — No way to trigger or return an error, since no form of RAISE is implemented. Yes, I know you can do other hacks to make it error, but that’s useless.

Stored Functions — I think they might have gotten stored functions right. They aren’t terribly complicated, though.

Triggers — Okay, I don’t even know where to start on triggers. They have a number of major problems:

  • Only one trigger per table per action — MySQL missed the point of one of the main applications of triggers: auditing. Since you can only have one trigger per table per action, you cannot use triggers for the typical application purposes at the same time as you use it for auditing. Yes, a single trigger can take more than one action, but that’s not the same thing.
  • Replication — Replication of triggers is still fundamentally broken in 5.0.19. You can, on the master, create a trigger that breaks replication. Yes, it’s fixed in 5.0.20, but that doesn’t help me, now does it?
  • Upgrading — An upgrade from 5.0.16 to 5.0.19 turned ugly because of some trigger compatibility issues.
  • Inconsistent syntax — There is no DROP TRIGGER IF EXISTS for some reason.
  • No atomic replacement — MySQL doesn’t support the OR REPLACE syntax to CREATE TRIGGER meaning that you cannot atomically replace (update the definition of) a trigger on a running installation. Strike two for using triggers for auditing.

Memory Leaks — Okay, this isn’t actually a feature, but a bug. A server running 5.0.19, using all of the above features except for views, is leaking memory like crazy. I’ll write a new post once I track it down.

How are you all dealing with MySQL 5.0? Are you as disappointed as I am?

UPDATE: Looks like stored procedures with replication is broken, too. :(