Jorgen Loland a écrit, Le 15.12.2010 10:59:
> On 11/26/2010 06:29 PM, Guilhem Bichot wrote:
>> #At
>> file:///home/mysql_src/bzrrepos_new/mysql-next-mr-opt-backporting-wl4800/
>> based on revid:guilhem@stripped
>>
>> 3238 Guilhem Bichot 2010-11-26
>> making use of sql_command_flags as advised by Davi
>>
>> modified:
>> sql/opt_trace2server.cc
>> sql/sql_class.h
>> sql/sql_parse.cc
>> - switch (sql_command)
>> - {
>> - case SQLCOM_SELECT: // includes EXPLAIN
>> - case SQLCOM_INSERT:
>> - case SQLCOM_INSERT_SELECT:
>> - case SQLCOM_REPLACE_SELECT:
>> - case SQLCOM_UPDATE:
>> - case SQLCOM_DELETE:
>> - case SQLCOM_UPDATE_MULTI:
>> - case SQLCOM_DELETE_MULTI:
>> - return false;
>> - default:
> ...
>> === modified file 'sql/sql_parse.cc'
>> --- a/sql/sql_parse.cc 2010-11-26 16:16:31 +0000
>> +++ b/sql/sql_parse.cc 2010-11-26 17:29:04 +0000
>> @@ -294,28 +294,37 @@ void init_update_queries(void)
>> sql_command_flags[SQLCOM_REPLACE]= CF_CHANGES_DATA |
>> CF_REEXECUTION_FRAGILE |
>> - CF_CAN_GENERATE_ROW_EVENTS;
>> + CF_CAN_GENERATE_ROW_EVENTS |
>> + CF_OPTIMIZER_TRACE;
>
> jl: Is it intentional to add SQLCOM_REPLACE to the list of traceable
> queries?
Yes. We already traced INSERT, and REPLACE is a variant of INSERT.
In fact, SQLCOM_INSERT means INSERT...VALUES(), which often gives an
uninteresting short trace of no value.
But if someone does:
INSERT ... VALUES(storedfunc());
and we don't trace INSERT, then we won't trace what storedfunc() does.
