Baron Schwartz wrote:
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.
Have you filed a feature request on this? I would agree that the list of
locks is certainly not of use to the average DBA, so removing this by
default would be a good idea.
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.
Sure it's an easy change to make in the code, but it could have
repercussions for all those monitoring tools/scripts out there already
that parse this 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!
Exactly! ;)
If 'you' have parsed the output in a sane manner, many tools should be
unaffected, however, we can not rely on that, and changing innodb status
could break a lot of scripts already made out there ;) This is why we
have to be very careful and considered in making these kinds of changes.
Of course, the burden is also on the InnoDB developers to do this.
We are also pretty committed within *MySQL* to maintain both SHOW and
INFORMATION_SCHEMA tables concurrently, I'm pretty sure the InnoDB
developers will be of the same mind as well (though I/'we' certainly do
not speak for them).
Cheers,
Mark
--
Mark Leith, Senior Support Engineer
MySQL AB, Worcester, England, www.mysql.com
Are you MySQL certified? www.mysql.com/certification
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
