maria-developers team mailing list archive

[Eric Bergen <eric.bergen@xxxxxxxxx>]

Hi Serg

On Tue, Aug 23, 2011 at 3:47 AM, Sergei Golubchik <serg@xxxxxxxxxxxx> 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.bergen@xxxxxxxxx
http://www.ebergen.net