Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
M
MariaDB
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
nexedi
MariaDB
Commits
b273e4a5
Commit
b273e4a5
authored
Mar 24, 2015
by
Sergei Petrunia
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Better comments
parent
1626e0d3
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
39 additions
and
4 deletions
+39
-4
sql/sql_explain.h
sql/sql_explain.h
+39
-4
No files found.
sql/sql_explain.h
View file @
b273e4a5
...
...
@@ -15,6 +15,43 @@
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */
/*
== EXPLAIN/ANALYZE architecture ==
=== [SHOW] EXPLAIN data ===
Query optimization produces two data structures:
1. execution data structures themselves (eg. JOINs, JOIN_TAB, etc, etc)
2. Explain data structures.
#2 are self contained set of data structures that has sufficient info to
produce output of SHOW EXPLAIN, EXPLAIN [FORMAT=JSON], or
ANALYZE [FORMAT=JSON], without accessing the execution data structures.
(the only exception is that Explain data structures keep Item* pointers,
and we require that one might call item->print(QT_EXPLAIN) when printing
FORMAT=JSON output)
=== ANALYZE data ===
EXPLAIN data structures have embedded ANALYZE data structures. These are
objects that are used to track how the parts of query plan were executed:
how many times each part of query plan was invoked, how many rows were
read/returned, etc.
Each execution data structure keeps a direct pointer to its ANALYZE data
structure. It is needed so that execution code can quickly increment the
counters.
(note that this increases the set of data that is frequently accessed
during the execution. What is the impact of this?)
Since ANALYZE/EXPLAIN data structures are separated from execution data
structures, it is easy to have them survive until the end of the query,
where we can return ANALYZE [FORMAT=JSON] output to the user, or print
it into the slow query log.
*/
class
String_list
:
public
List
<
char
>
{
public:
...
...
@@ -43,7 +80,6 @@ class Table_access_tracker
ha_rows
r_scans
;
/* How many scans were ran on this join_tab */
ha_rows
r_rows
;
/* How many rows we've got after that */
// ha_rows r_rows_after_table_cond; /* Rows after applying the table condition */
ha_rows
r_rows_after_where
;
/* Rows after applying attached part of WHERE */
bool
has_scans
()
{
return
(
r_scans
!=
0
);
}
...
...
@@ -103,7 +139,7 @@ class Table_op_tracker
{ tracker->stop_tracking(); }
/*
A class for tracking
execution time
A class for tracking
time it takes to do a certain action
*/
class
Exec_time_tracker
{
...
...
@@ -127,7 +163,6 @@ class Exec_time_tracker
}
// interface for getting the time
//loops, starts, stops
ulonglong
get_loops
()
{
return
count
;
}
double
get_time_ms
()
{
...
...
@@ -710,7 +745,7 @@ class Explain_table_access : public Sql_alloc
// Valid if ET_USING tag is present
Explain_quick_select
*
quick_info
;
/* Non-NULL value
s
means this tab uses "range checked for each record" */
/* Non-NULL value means this tab uses "range checked for each record" */
Explain_range_checked_fer
*
range_checked_fer
;
bool
full_scan_on_null_key
;
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment