On Jan 12, 2010, at 3:30 PM, Baron Schwartz wrote: > Hi Tim, > > On Tue, Jan 12, 2010 at 4:24 PM, Tim Soderstrom > <[email protected]> wrote: >>> If I can further hijack the thread, the whole session -vs- global >>> thing is horrible. The only real use I've seen is for things like >>> per-thread buffers -- and if anything, those should be implemented as >>> query hints embedded in the SQL itself. The same comment applies to >>> global -vs- session status counters -- having a mixture of them come >>> back from SHOW STATUS is, um, horrible. Maybe Drizzle already >>> un-borked this, dunno. >> >> I have to disagree with you there, Baron. I use per session counters quite >> often as part of troubleshooting bad performance. How else do I know if a >> query creates a temporary table on disk or is going a sort merge pass? It's >> cake with session variables. I'd like to see these left around myself, > > I want them to stay -- in fact I want MUCH more instrumentation. I'm > not advocating for less. But having them be named the same thing in > two scopes, with no way to know what you're getting, is a disaster. > Even something this simple would be wonderful: > > scope name value > --------- ---------- -------------- > | session | Questions | 100 | > | global | Questions | 1000 | > > Jeremy Cole had a good blog post (and bug report) on this too.
Aha! Yeah that makes a lot more sense. That's definitely something I'd like to see there as well. And I'm guessing differentiating the two would be easy to do if this stuff is provided as part of the new information_schema? Tim _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
