maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxxx>]

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.

> 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...

Regards,
Sergei