Hi Serg On Tue, Aug 23, 2011 at 3:47 AM, Sergei Golubchik <s...@askmonty.org> wrote: > Hi, Eric! > > On Jul 28, Eric Bergen wrote: >> Hi, >> >> I've been working on some improvements to the table and index >> statistics in mariadb that allow tracking on the session and query >> level. I've been pushing the changes to >> lp:~provenscaling-eric/maria/tivo The long form version of where I'm >> at in my hacking is at >> >> http://ebergen.net/wordpress/2011/07/28/second-update-of-modifying-table-statistics-in-mariadb/ >> >> I want to poll this list for ides on a few places I'm stuck and get >> the review process started to hopefully get some of these changes >> merged back into mainline mariadb. My first issue is around allocation >> of query ids for both show profiles and show table_statistics; Table >> statistics are enabled by userstat and profiles are controlled by >> profiling. Enabling these options at different times makes some >> confusing results: > > Why wouldn't you introduce a persistent session query counter? > Like, put it in thd, increment on every query, and show this number in > profiling and userstat.
I did that. It functions fine but it means that someone enabling profiling mid way through a session won't start with profile id 1 like they used to. > >> My current thought is to create a show query history command that >> unifies both show profiles and user stats but only table stats or >> profiles will be available for any given query depending on the flags >> set when it ran. I can also create a separate show queries command >> only for table statistics. Any ideas on how to unify the two different >> profiling methods or split up the syntax? > > Ah, good idea. Indeed, both profiling and userstat need to keep the list > of queries. It would make sense to have internal query history API, > something like: > > enable_query_history() - can be called by profiling or userstat > disable_query_history() > get_query_str(id) > get_query_count() > > you can keep it completely internal, without SHOW command. > but both profiling and userstat will get access to query text pointers > via get_query_str(). So, they'll have consistent query ids, they won't > copy query text twice, etc. > > Note that enable_query_history() can be called many times, like > > set profiling=1; > -> enable_query_history(); > > set userstat=1; > -> enable_query_history(); > > set profiling=0; > -> disable_query_history(); > ^^^ this should not disable history, as userstat needs it. > > probably enable/disable should maintain a counter... > If everyone is ok with the profile id issue I highlighted above and having this change impact both profiling and table statistics I can go ahead and implement it. > Regards, > Sergei > -- Eric Bergen eric.ber...@gmail.com http://www.ebergen.net _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
