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.
numbers, which uses "X.YeZ" notation when the exponent Z would be
less than -4. That behavior at -4 is not exactly what we want, and
our Decimal type offers smarter number representation. By changing
profiling to use Decimal types, we get more readable output.
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.
renamed. Some new THD proc_info states are new. Directories must be
encountered in make in a specific order, to have symlinks already set.
Move community-server-specific tests into own tests, so that we can
exempt them from testing on enterprise servers.
Add a new autoconf paremeter --{en,dis}able-community-features . The
default is disable for enterprise servers.
Though this is a 5.0 tree, it is only to be merged into the 5.0-community
tree and the global 5.1 tree, never to the 5.0-enterprise tree.
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.
B-g#27060: SQL Profile utility may not be reporting right duration \
for each step
Whenever the profiler is reset at the beginning of a query, there's
a "hidden" profiling entry that represents that point in time. It
has no status description, as those are set by state changes and no
such point has yet been encountered. That profiling entry is not
in the list of entries generated when we change states.
The profiling code had the problem that each step of printing
profiling data subtracted the previous "step"'s data, but gave the
label to that data of the current step, which is wrong. The label/
state refers to the period beginning with that profiling data, not
ending with it.
Now, give a label to the first profiling pseudo-entry, so that we
have a name to assign to the period that ends with the first state
change. Now also use the state name of the previous step in showing
the delta values that end with this step.
B-g#24795: SHOW PROFILE implementation
Don't use memory roots to store profiling information, because
memory roots make freeing the data a no-op, and thus long-running
processes with profiling turned on the whole time could eventually
use all available memory.
Instead, use regular heap allocation and deallocation calls to
manage profiling data. Replace the leaky List usage with a similar-
behaving structure named "Queue".
Expand float size to avoid assert()ion failures.
"_db_func_" isn't a known linked object on some platforms, possibly
because it is occasionaly shadowed by DBUG variables. Avoid that
confusion.
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.
