| Bug #33321 | print_plan does not print appropriate values. | ||
|---|---|---|---|
| Submitted: | 18 Dec 2007 6:34 | Modified: | 18 Feb 2014 15:43 |
| Reporter: | Sadao Hiratsuka (Basic Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Optimizer | Severity: | S3 (Non-critical) |
| Version: | 5.0.52, 5.0-bzr, 5.1-bzr | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | Optimizer, print_plan, qc | ||
[31 Mar 2009 16:24]
Valeriy Kravchuk
I can confirm that we still have this calls in the
best_extension_by_limited_search() function in current 5.0 sources from bzr:
DBUG_EXECUTE("opt", print_plan(join, idx, record_count, read_time, read_time,
"part_plan"););
DBUG_EXECUTE("opt", print_plan(join, idx+1,
current_record_count,
read_time,
(current_read_time +
current_record_count /
(double) TIME_FOR_COMPARE),
"prune_by_cost"););
DBUG_EXECUTE("opt", print_plan(join, idx+1,
current_record_count,
read_time,
current_read_time,
"pruned_by_heuristic"););
DBUG_EXECUTE("opt", print_plan(join, idx+1,
current_record_count,
read_time,
current_read_time,
"full_plan"););
Also note that print_plan() is defined in sql/sql_test.cc as follows:
/*
Print the current state during query optimization.
SYNOPSIS
print_plan()
join pointer to the structure providing all context info for
the query
read_time the cost of the best partial plan
record_count estimate for the number of records returned by the best
partial plan
idx length of the partial QEP in 'join->positions';
also an index in the array 'join->best_ref';
info comment string to appear above the printout
DESCRIPTION
This function prints to the log file DBUG_FILE the members of 'join' that
are used during query optimization (join->positions, join->best_positions,
and join->best_ref) and few other related variables (read_time,
record_count).
Useful to trace query optimizer functions.
RETURN
None
*/
void
print_plan(JOIN* join, uint idx, double record_count, double read_time,
double current_read_time, const char *info)
{
...
}
As you can see, read_time is explained as "the cost of the best partial plan", but there is NO explanation what current_read_time is then.
I think we need at least more clear comments here.
[18 Feb 2014 15:43]
Paul DuBois
Per the development team, this is not a bug, but the print_plan() function header comment was not clear. To address this, the comment has been revised to be more informative.
[18 Feb 2014 15:43]
Paul DuBois
The change was made in 5.7.4.
Description: print_plan does not print appropriate values in best_extension_by_limited_search(). How to repeat: sql/sql_select.cc best_extension_by_limited_search() There are 4 points calling print_plan(). It is called in debug mode. (1) part_plan DBUG_EXECUTE("opt", print_plan(join, idx, record_count, read_time, read_time, "part_plan"); ); (2) pruned_by_cost DBUG_EXECUTE("opt", print_plan(join, idx+1, current_record_count, read_time, ( current_read_time + current_record_count / (double) TIME_FOR_COMPARE ), "prune_by_cost"); ); (3) pruned_by_heuristic DBUG_EXECUTE("opt", print_plan(join, idx+1, current_record_count, read_time, current_read_time, "pruned_by_heuristic"); ); (4) full_plan DBUG_EXECUTE("opt", print_plan(join, idx+1, current_record_count, read_time, current_read_time, "full_plan"); ); <4th parameter> I think this parameter shows previous value of read_time. (1) does not show previous value. (2) shows previous value. (3) shows previous value. (4) shows previous value. There are mismatches. <5th parameter> I think this parameter shows cost of the plan. (1) does not show cost value. (shows only read_time) (2) shows cost value. (3) does not show cost value. (shows only read_time) (4) shows cost value. (current_read_time contains current_record_count value at this time) There are mismatches. Suggested fix: Please display uniform contents.