List:Commits« Previous MessageNext Message »
From:Guilhem Bichot Date:May 23 2011 1:22pm
Subject:Re: bzr commit into mysql-trunk branch (tor.didriksen:3313)
View as plain text  
Tor Didriksen a écrit, Le 23.05.2011 09:12:
> #At file:///export/home/didrik/repo/next-mr-opt-backporting-wl4800/ based on
> revid:guilhem.bichot@stripped
> 
>  3313 Tor Didriksen	2011-05-23
>       comments on TODO list
> 
>     modified:
>       WL4800_TODO.txt
>       sql/opt_trace.h
> === modified file 'WL4800_TODO.txt'
> --- a/WL4800_TODO.txt	2011-05-20 13:15:22 +0000
> +++ b/WL4800_TODO.txt	2011-05-23 07:12:10 +0000
> @@ -27,6 +27,7 @@ version number in order to distinguish b
>  not forget to bump the version when doing certain changes (and: what
>  changes? any little change? maybe).
>  Guilhem suggests: don't have a version.
> +I agree.

ok

>  C3) Jorgen wrote: The optimizer may have second thoughts about which access method
> to
>  use for a table. This should be traced. See example query (1) where
> @@ -43,12 +44,14 @@ Guilhem asks: good idea, but how much is
>  --explain-protocol, --sp-protocol, --view-protocol make all tests
>  fail. Maybe I can merely move this as an idea in a comment in mysqltest.cc
>  near the definition of opt-trace-protocol?
> +This would be a relly nice feature. Don't know how much work it is though.

We would also need to define it.
Right now, the trace is put in the test's output, so one gets:

normal test output ("echo"-based informative comments, query, result)
trace
normal test output
trace

so the reader sees the "context" of the trace.

If we dump to a separate file:
- how do we name it: <testname>.opt_trace?
- what do we put in the file? it will look like

trace
trace

which will be harder to relate to a certain test portion. The 
OPTIMIZER_TRACE table does contain the query, but for tests which run 
the same query several times, the query is not enough context.
We can improve a bit:

lineno trace
lineno trace

where lineno is the number of the line in the test file which caused 
this trace.

It's still not as good as the "directly-in-output" trace which we have now.

I suggest we continue living with the current situation. Making tests 
fail causes server restarts and thus slowdowns, on the other hand, we 
don't use the option that much, so the slowdown is rarely experienced... 
I think we use --opt-trace-protocol to run the full suite and grep all 
traces for a certain word, to find tests which exercise a certain piece 
of the optimizer. That is not so common. I alternatively use 
--mysqld=--optimizer-trace=enabled=on; it does not print the trace; but 
is good enough to find trace-related crashes or bad query results.

>  C5) should the debug binary really assert(0) if json syntax error? is it a
>  good idea at the customer's? On the other hand, how to make sure a
>  developer notices a syntax error when running tests?
>  sql_print_warning() is an idea.
>  Guilhem suggests: keep it as it is (assert(0))
> +Let's keep it, at least for now.

ok
Thread
bzr commit into mysql-trunk branch (tor.didriksen:3313) Tor Didriksen23 May
  • Re: bzr commit into mysql-trunk branch (tor.didriksen:3313)Guilhem Bichot23 May