- Query plan footprint (in new terms, "EXPLAIN structure") should always keep
a copy of key_name. This is because the table might be a temporary table which
may be already freed by the time we use query plan footprint.
- Make QPF structures store data members, not strings.
This is not fully possible, because table names (and hence
key names, etc) can be deleted, and we have to store strings.
- Make query plan be re-saved after the first join execution
(saving it after JOIN::cleanup is too late because EXPLAIN output
is currently produced before that)
- Handle QPF allocation/deallocation for edge cases, like unsuccessful
BINLOG command.
- Work around the problem with UNION's direct subselects not being visible.
- Update test results ("Using temporary; Using filesort" are now always printed
last in the Extra column)
- This cset gets rid of memory leaks/crashes. Some result mismatches still remain.
- Handle another specific case where there the JOIN
never had a query plan, but had multiple join->cleanup(full=true) calls
- The idea that there can only be MAX_TABLES subuqeries/unions was
wrong. Switch QPF_query to using a Dynamic_array.
= make Dynamic_array template support size growth. its underlying
DYNAMIC_ARRAY supports it. (this part will need more polishing)
- Handle statements inside SPs:
= regular statements
= SET command, which does not have its own statement.
- Handle execution of subquery from range optimizer:
allocate subquery QPFs on the same MEM_ROOT as the whole
query plan was allocated.
Single table UPDATE/DELETE
- Correctly print type=SIMPLE vs type=PRIMARY
- Handle UPDATE/DELETE of mergeable VIEWs: we get the
VIEW's select as the first subquery.
(MySQL 5.6 doesn't print it because it finds that the
subquery is not attached to any select)
- Introduce back QueryPlan/QueryPlanFootprint separation for
single-table UPDATEs/DELETEs
- Create an empty QueryPlanFootprint for all kinds of queries
- Introduce "Query Plan Footprints" (abbrev. QPFs)
QPF is a part of query plan that is
1. sufficient to produce EXPLAIN output,
2. can be used to produce EXPLAIN output even after its subquery/union
was executed and deleted
3. is cheap to save so that we can always save query plans
- This patch doesn't fully address #2, we make/save strings for
a number of EXPLAIN's columns. This will be fixed.
