On 12/11/2008, at 4:42 PM, Wultsch wrote:
>> Bug description:
>> When long_query_time is really small, the slow log will also see
>> queries that are not actually executed, for instance because of a
>> syntax error. Naturally this is not desirable behaviour.
>>
>> The probable cause is actually likely to be with the original slow
>> query log code and not with the microslow patch as such; with
>> second-granularity, no syntax error query would ever take longer
>> than a second to get through the parsing stage....
>>
>
> I think this is not a bug. If a DBA decides that any query over that
> takes over some period of time should be logged, and a query (with a
> syntax error, or not) takes longer than that period it __should__ be
> logged.
>
> As long as the behavior is documented I do not see it as problematic.
The slow log is intended for execution time, queries with syntax
errors are not executed.
An error is an error, it already reports back instantly on the client
side... what would be the practical purpose of logging it in the slow
log?
I use a very low long_query_time in training to show how queries are
executed (mem/disk tmp table, mem/disk sort, etc); of course I make
typos on the cmdline client while typing, don't want all that junk
logged.
On 12/11/2008, at 4:42 PM, Wultsch wrote:
>> Bug description:
>> When long_query_time is really small, the slow log will also see
>> queries that are not actually executed, for instance because of a
>> syntax error. Naturally this is not desirable behaviour.
>>
>> The probable cause is actually likely to be with the original slow
>> query log code and not with the microslow patch as such; with
>> second-granularity, no syntax error query would ever take longer
>> than a second to get through the parsing stage....
>>
>
> I think this is not a bug. If a DBA decides that any query over that
> takes over some period of time should be logged, and a query (with a
> syntax error, or not) takes longer than that period it __should__ be
> logged.
>
> As long as the behavior is documented I do not see it as problematic.
The slow log is intended for execution time, queries with syntax
errors are not executed.
An error is an error, it already reports back instantly on the client
side... what would be the practical purpose of logging it in the slow
log?
I use a very low long_query_time in training to show how queries are
executed (mem/disk tmp table, mem/disk sort, etc); of course I make
typos on the cmdline client while typing, don't want all that junk
logged.