Mark Leith wrote:
Baron Schwartz wrote:
I stand corrected. I don't know why I didn't think of this!
So you guys had to go the route of parsing InnoDB status too, huh?
Fun, isn't it!
Indeed, it is a rather interesting thing to do ;) Made even better when
it is limited to 64K and truncated with large transactions!
Or a big deadlock with tons of tuples. I have submitted a feature
request to remove the list of locks held, but I don't know how high a
priority it's given. It's useless for non-developers, though Heikki
told me he uses it every day. I wouldn't think it'd be hard to define a
compile-time option whether to include all the tuples locked, so Heikki
and Marko could see it but spare the rest of us :) Of course seeing
just the first part of that output, which shows what kind of lock was
held on which index, is very useful for non-InnoDB-developers too.
Google did some smart stuff altering this (moving the 'dynamic' content
such as deadlocks, transactions etc.) to the end of the output, and
increasing the limit to 128K, however I'm not sure whether we will see
that in the server soon. You can see examples here:
http://dammit.lt/2007/06/23/mysql-40-google-edition/
Yes, Mark told me about that, and I thought it was a great idea. I
don't know why we shouldn't see that in the server soon. It's not a
hard thing to do, just a few lines changed, right? It seems kind of
obvious that it's better to put the potentially huge deadlock output
after the 'important' stuff.
I have seen that the InnoDB developers are looking at moving some of the
output over to INFORMATION_SCHEMA tables as well (they mentioned this on
the internals@ list), so hopefully this should all become a little
easier in the not too distant future!
Yep. But there's always that legacy support you have to keep around!
Baron
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
