Between 5.0 and 5.1, the step of incrementing the global query id
changed, which broke how the profiler noticed when a new query had
started. That reset the state list and caused all but the last
five (or so) states to be thrown away.
Now, don't watch for query_id changes in the lower level.
Add a bogus state change at the end of profiling so that the last
real state change is timed.
Emit source reference for the start of the span of time instead of
the end of it.
profiling. Also,
Bug#26938: profiling client hang if used before enabled
In the SHOW command, not sending header data because we had no
rows to send was a protocol violation. Porting the SHOW PROFILE
command to use the Information Schema table avoids that problem.
halfway through a query (as happens in "SET SESSION PROFILING = ...")
has a few side-effects, the worst of which is a memory leak for
prepared statements, which poke directly from the parser into the
profiling code (we don't have the query text when we need it) and
that overwrites a pointer to heap-allocated memory when the previous
statement turns on profiling.
Instead, now set a flag when we begin a new statement that tracks
whether profiling is on _at the start_ of the query. Use that to
track whether we gather info.
Additionally, use that AND use the state of the profiling variable
after the end of a query to know whether to store information about
the query that just finished.
is a special case in "SHOW PROFILE FOR QUERY n". No one can get
the zero item (which is always the statement that turns on profiling),
because zero represents the final item, internally.
Now, order the queries starting at one.
B-g#27501: 5.0 significantly more sys ("kernel") time than 4.1 \
due to getrusage() calls
Even if profiling is turned off, the parser makes calls to reset
the state at the beginning of each query. That would eventually
instantiate a PROFILE_ENTRY, which does indeed capture resource
usage.
Instead, now check that profiling is active before progressing
far into the storage/expiration of old entries in the history.
This has the pleasant side-effect that queries to toggle profiling
are not recorded in the history.
to a single statement.
---
Bug#24795: SHOW PROFILE
Profiling is only partially functional on some architectures. Where
there is no getrusage() system call, presently Null values are
returned where it would be required. Notably, Windows needs some love
applied to make it as useful.
Syntax this adds:
SHOW PROFILES
SHOW PROFILE [types] [FOR QUERY n] [OFFSET n] [LIMIT n]
where "n" is an integer
and "types" is zero or many (comma-separated) of
"CPU"
"MEMORY" (not presently supported)
"BLOCK IO"
"CONTEXT SWITCHES"
"PAGE FAULTS"
"IPC"
"SWAPS"
"SOURCE"
"ALL"
It also adds a session variable (boolean) "profiling", set to "no"
by default, and (integer) profiling_history_size, set to 15 by
default.
This patch abstracts setting THDs' "proc_info" behind a macro that
can be used as a hook into the profiling code when profiling
support is compiled in. All future code in this line should use
that mechanism for setting thd->proc_info.
---
Tests are now set to omit the statistics.
---
Adds an Information_schema table, "profiling" for access to
"show profile" data.
---
Merge zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-community-3--bug24795
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-community
---
Fix merge problems.
---
Fixed one bug in the query_source being NULL.
Updated test results.
---
Include more thorough profiling tests.
Improve support for prepared statements.
Use session-specific query IDs, starting at zero.
---
Selecting from I_S.profiling is no longer quashed in profiling, as
requested by Giuseppe.
Limit the size of captured query text.
No longer log queries that are zero length.
