?

Log in

No account? Create an account

Friday, Finding a bug...

« previous entry | next entry »
Jan. 12th, 2007 | 05:44 pm

You know, sometimes there is nothing like finding the bug you have been hunting for, for a couple of days, on a Friday at 5:40 PM.

The optimize() call in Archive didn't have the right table buffer after someone updated the call to field->offset(). Tricky little thing... heisenbug (and no this is not in any release of 5.1 as far as I can tell, recent change).

Ok, technically this is a shroedinbug.
Tags:

Link | Leave a comment | Share

Comments {3}

(no subject)

from: jamesd
date: Jan. 13th, 2007 12:43 pm (UTC)
Link

Friday was a good day for bugs. It was discovered that the Cluster engine was doing a full table scan to get stats for the query optimiser. Even for single row lookups by PK. Maybe NDBAPI will stop being much faster than the storage interface soon.

Reply | Thread

Clarification

from: tomas_ulin
date: Jan. 18th, 2007 02:13 am (UTC)
Link

jamesd,

the bug discovered was introduced in 5.0 in June last summer. The bug means that the mysql server optimizer will fetch the actual (exact) row count from a table to be used for query planning, although an estimate would suffice. In case of a ndb table type, this will mean an extra round trip over the network to fetch the row count, and the relative penalty for this is high for primary key operations, hence a performace bug. Note that there is no full table scan happening, just a parallell scan of the table fragments to fetch the row count.

The bug fix is to replace the fetch of the exact count, with a cached estimate.

BR,

Tomas
MySQL Cluster Development Lead

Reply | Parent | Thread

Re: Clarification

from: jamesd
date: Jan. 18th, 2007 02:32 pm (UTC)
Link

Tomas, thanks for the clarification of the initial report. That is better than asking all of the nodes for exact counts. I'm glad to read that the extra round-trips will soon be avoided.

On a different subject, congratulations on all of the major sales successes that your Cluster team is behind! Hard work but if you want to take over a significant part of the database world, you're heading in that direction.

Reply | Parent | Thread