Any chance of that code being released in the next 60 days or so?
Hi!Which tree are you referring to? Compared Innodb to Falcon lately? Jim believes this is one of his killer bits for Falcon.Cheers, -Brian
The code is in a local tree at work and will be published after it gets used (a few months).Falcon has been 2X to 8X slower than InnoDB for me on tests with no concurrency (1 session). With the InnoDB fixes that we are testing, InnoDB performance doesn't degrade and the InnoDB performance advantage is maintained at high levels of concurrency.
To clarify my claim about performance, when I use SQL statements that access many rows, InnoDB is much faster than Falcon. If I limit the workload to select/update statements that access 1 row, performance is similar.
Well, its something to look forward to. I'm somewhat used to innodb's quirks, so a this point I'd be more comfortable applying and testing a patch to innodb for improved performance than to switch to falcon. PS Is blogger broken? Why am I now refereed to as water outbreaks? I think that might have been the last search through google books, but a strange profile name. Oh well, It could be worse the best nicknames are accidents.
Great to hear Mark. It would be interesting to see what have you guys fixed with Innodb as were seems to be plenty contention points. So it would be interesting to see if you've fixed all of them :)Regarding single row lookups - no surprise here the parsing network communication is largest part for those rows on CPU bound workloads.
More work remains, but things are better. Yasufumi Kinoshita is working on these problems too and has published a patch to make the rw-mutex much faster.
NICE. DO WANT. I'll be at your talk.Luckily I'm not looking at 8 core machines just yet.Though, InnoDB is feeling the pain on quad core.Any chance these patches will work with 4.1?Kevin
are you releasing that for 4.0? ;-)
We are on 5.0.37, so the next patch will be on a version >= 5.0.37.
You had me at "InnoDB" :-)
looking forward to your talk since I'm also in a situation in which the majority of our queries access more than 1 row.