On Jan 12, 2010, at 3:18 PM, Baron Schwartz wrote: > Hi, > > On Tue, Jan 12, 2010 at 1:32 AM, Morgan Tocker <[email protected]> wrote: >>> key_buffer_size => myisam_key_cache_size >>> key_cache_block_size => myisam_key_cache_block_size >>> key_cache_division_limit => myisam_key_cache_division_limit >>> key_cache_age_threshold => myisam_key_cache_age_threshold >> >> ++ >> >> This might not be the right thread to hijack, but is there any >> proposal to change the names so I can tell if it applies to session or >> global scope? > > 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, but that's just me. Same sort of holds true for per-session variables. A great example there is to have a low interactive_timeout globally but set it higher when you know you will be leaving the connection open (such as when running a big reporting script that does a lot of processing in between SQL queries). I don't see how per session stats or vars are hurting anyone here. I'm open to a superior solution but I would like to see them, or something like them, stick around. $0.02 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
