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.
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.
(no subject)
from:
jamesd
date: Jan. 13th, 2007 12:43 pm (UTC)
Link
Reply | Thread
Clarification
from:
tomas_ulin
date: Jan. 18th, 2007 02:13 am (UTC)
Link
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
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