bzr commit into mysql-next-mr-opt-backporting branch (guilhem:3198)

[Guilhem Bichot]

#At file:///home/mysql_src/bzrrepos_new/mysql-next-mr-opt-backporting-wl4800/ based on revid:guilhem@stripped

 3198 Guilhem Bichot	2010-09-03
      details

    modified:
      WL4800_TODO.txt
      mysql-test/include/optimizer_trace.inc
      sql/opt_trace.h
=== modified file 'WL4800_TODO.txt'
--- a/WL4800_TODO.txt	2010-09-02 21:00:12 +0000
+++ b/WL4800_TODO.txt	2010-09-03 08:18:12 +0000
@@ -1,25 +1,12 @@
 Short-term TODO list to remember for WL#4800
 ============================================
 
-An object under construction may be printed to the debug output
-interleaved with other DBUG_PRINT: the object will look "split" and be
-hard to read. This could be improved by writing object pieces in
-qualified form ("object_name.property: x") instead of "property: x").
-What has been implemented for now is that Optimizer_trace prints to
-DBUG as soon as it adds a property, and does not use a qualified name
-(which will require tracking of parents' names).
-
 void QUICK_RANGE_SELECT::dbug_dump(int indent, bool verbose)
 doesn't use "verbose".
 
 ./mtr --mem  --mysqld=--optimizer_trace=1 main.ctype_* gives warnings
 ("Incorrect string value") etc: another incarnation of BUG#50677.
 
-option to limit trace size in memory, issue warning if truncated
-
-support LIMIT and OFFSET variables to retain only certain traces (see
-WL#5257).
-
 convert obscure names like range_select quick_condition_rows (etc?) to
 user-friendly descriptive self-explanatory names.
 
@@ -32,8 +19,7 @@ rsync -avz /m/doxygen/mysql-wl4800 [URL]
 
 fix bugs recorded in optimizer_trace_bugs.test and delete that test.
 
-test with UNION, VIEWS (mergeable or not), UNION of two subqueries,
-INFORMATION_SCHEMA tables.
+test with VIEWS (mergeable or not), INFORMATION_SCHEMA tables.
 
 Put in the trace some way to relate "select #N" to the corresponding
 SELECT.
@@ -46,4 +32,10 @@ version number in order to distinguish b
 not forget to bump the version when doing certain changes (and: what
 changes? any little change? maybe).
 
+Coding style:
 Make sure long code lines are wrapped.
+
+To do to implement design of WL#5257:
+- option to limit trace size in memory, issue warning if truncated
+- support LIMIT and OFFSET variables to retain only certain traces
+

=== modified file 'mysql-test/include/optimizer_trace.inc'
--- a/mysql-test/include/optimizer_trace.inc	2010-09-02 20:08:59 +0000
+++ b/mysql-test/include/optimizer_trace.inc	2010-09-03 08:18:12 +0000
@@ -15,6 +15,11 @@
 # It's also skipped in sp-protocol for the same reason (SELECT becomes
 # CALL).
 
+# When adding tests here, try to have some of them use SELECT and
+# others use EXPLAIN SELECT, to verify that both ways give sufficient
+# tracing.
+
+# should be empty
 select * from information_schema.OPTIMIZER_TRACE;
 
 set @@session.optimizer_trace="enabled=on";

=== modified file 'sql/opt_trace.h'
--- a/sql/opt_trace.h	2010-09-02 21:00:12 +0000
+++ b/sql/opt_trace.h	2010-09-03 08:18:12 +0000
@@ -87,6 +87,17 @@
   SELECT * FROM information_schema.OPTIMIZER_TRACE;
 @endverbatim
 
+  @c SELECT and @c EXPLAIN SELECT produce the same trace. But there are
+  exceptions regarding subqueries because the two commands treat subqueries
+  differently, for example in
+@verbatim
+  SELECT ... WHERE x IN (subq1) AND y IN (subq2)
+@endverbatim
+  SELECT terminates after executing the first subquery if the related IN
+  predicate is false, so we won't see @c JOIN::optimize() tracing for subq2;
+  whereas EXPLAIN SELECT analyzes all subqueries (see loop at the end of @c
+  select_describe()).
+
   @section DEV_ADDS_TRACING How a developer adds tracing to a function
 
   Check @c Opt_trace* usage in @c advance_sj_state():


Attachment: [text/bzr-bundle] bzr/[e-mail]