List:Commits« Previous MessageNext Message »
From:Gleb Shchepa Date:July 10 2007 9:04am
Subject:Re: bk commit into 5.0 tree (gshchepa:1.2525) BUG#29338
View as plain text  
Konstantin Osipov wrote:
> * gshchepa@stripped <gshchepa@stripped> [07/07/10 04:52]:
> 
>> ChangeSet@stripped, 2007-07-10 05:26:54+05:00, gshchepa@stripped +7 -0
>>   Fixed bug #29338.
>>   Trivial stored functions that consist of RETURN <constant expression>
>>   operator was evaluated ineffectively.
>>   This type of SF may be commonly used as named constants, so optimizations
>>   is desirable.
> 
> The original complain was about deterministic functions.
> 
> Where do you check for DETERMINISTIC clause?


Original complain is inaccurate:
The DETERMINISTIC clause doesn't guarantee no side effects like
reading and changing of global or session variables.
So, the optimization based on the DETERMINISTIC clause only may
significantly change query result (even if the implementation
of DETERMINISTIC clause will be improved to conform it's definition:
always produces the same result for the same input parameters).

My optimization does nothing with DETERMINISTIC, it optimizes
particular case of both DETERMINISTIC and non-DETERMINISTIC functions.
Of course, my fix covers complained problem.


> 
> Evaluation of properties of a stored function should happen when
> it's loaded, not at every execution.
> 
> Evaluation of 'const' property of an item should happen when this
> item is prepared, not at every execution.
> 
> RAND_TABLE_BIT might also be used by the query cache.
> 
> Item::const_item() and Item::basic_const_item() interfaces are a
> mess. In some places they are used as input for making a
> reinterpret_cast. Please do not add anything on top of this
> unclear interface before clarifying in detail how they are
> supposed to work and how they are used by the optimizer.
> 
> The test coverage is very scarce.
> 
> Trudy: to me it's clearly a feature request, thus such a high 
> priority is questionable. 
> Even more questionable to push this into 5.0.


I agree, this task is a feature request. It looks like regression because before
#27354 fix most of SF was treated as constant functions without side effects
(usually it is wrong).

Also this is a duplicate of bugs #21314 and #14669.


> 
> Would be nice to have a worklog task too.
> 

Thread
bk commit into 5.0 tree (gshchepa:1.2525) BUG#29338gshchepa10 Jul
  • Re: bk commit into 5.0 tree (gshchepa:1.2525) BUG#29338Konstantin Osipov10 Jul
    • Re: bk commit into 5.0 tree (gshchepa:1.2525) BUG#29338Gleb Shchepa10 Jul
  • Re: bk commit into 5.0 tree (gshchepa:1.2525) BUG#29338Trudy Pelzer10 Jul
    • Re: bk commit into 5.0 tree (gshchepa:1.2525) BUG#29338Gleb Shchepa10 Jul