An error occurred fetching the project authors.
- 22 Dec, 2006 1 commit
-
-
cmiller@zippy.cornsilk.net authored
When only one row was present, the subtraction of nearly the same number resulted in catastropic cancellation, introducing an error in the VARIANCE calculation near 1e-15. That was sqrt()ed to get STDDEV, the error was escallated to near 1e-8. The simple fix of testing for a row count of 1 and forcing that to yield 0.0 is insufficient, as two rows of the same value should also have a variance of 0.0, yet the error would be about the same. So, this patch changes the formula that computes the VARIANCE to be one that is not subject to catastrophic cancellation. In addition, it now uses only (faster-than-decimal) floating point numbers to calculate, and renders that to other types on demand.
-
- 30 Nov, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
merge fix : removed undeterministic warnings
-
- 28 Nov, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
When implicitly converting string fields to numbers the string-to-number conversion error was not sent to the client. Added code to send the conversion error as warning. We also need to prevent generation of warnings from the places where val_xxx() methods are called for the sole purpose of updating the Item::null_value flag. To achieve that a special function is added (and called) : update_null_value(). This function will set the no_errors flag and will call val_xxx(). The warning generation in Field_string::val_xxx() will use the flag when generating the conversion warnings.
-
- 31 Oct, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
Item::val_xxx() may be called by the server several times at execute time for a single query. Calls to val_xxx() may be very expensive and sometimes (count(distinct), sum(distinct), avg(distinct)) not possible. To avoid that problem the results of calculation for these aggregate functions are cached so that val_xxx() methods just return the calculated value for the second and subsequent calls.
-
- 20 Sep, 2006 1 commit
-
-
gkodinov/kgeorge@rakia.(none) authored
-
- 08 Sep, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
wrong results Mark the containing Item(s) (Item_subselect descendant usually) of a subselect as containing aggregate functions if it has references to aggregates functions that are calculated outside its context. This tels end_send_group() not to make an Item_subselect descendant in select list a copy and causes the correct value being returned.
-
- 05 Sep, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
-
- 14 Aug, 2006 1 commit
-
-
kostja@bodhi.local authored
-
- 10 Aug, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
Treat queries with no FROM and aggregate functions as normal queries, so the aggregate function get correctly calculated as if there is 1 row. This means that they will be considered to have one row, so COUNT(*) will return 1 instead of 0. Other aggregates will behave in compatible manner.
-
- 31 Jul, 2006 1 commit
-
-
evgen@moonbone.local authored
After merge fix
-
- 28 Jul, 2006 1 commit
-
-
sergefp@mysql.com authored
- Make the range-et-al optimizer produce E(#table records after table condition is applied), - Make the join optimizer use this value, - Add "filtered" column to EXPLAIN EXTENDED to show fraction of records left after table condition is applied - Adjust test results, add comments
-
- 25 Jul, 2006 1 commit
-
-
timour/timka@lamia.home authored
The problem was in that opt_sum_query() replaced MIN/MAX functions with the corresponding constant found in a key, but due to imprecise representation of float numbers, when evaluating the where clause, this comparison failed. When MIN/MAX optimization detects that all tables can be removed, also remove all conjuncts in a where clause that refer to these tables. As a result of this fix, these conditions are not evaluated twice, and in the case of float number comparisons we do not discard result rows due to imprecise float representation. As a side-effect this fix also corrects an unnoticed problem in bug 12882.
-
- 21 Jul, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
An aggregate function reference was resolved incorrectly and caused a crash in count_field_types. Must use real_item() to get to the real Item instance through the reference
-
- 16 Jun, 2006 1 commit
-
-
igor@rurik.mysql.com authored
-
- 14 Jun, 2006 1 commit
-
-
igor@rurik.mysql.com authored
-
- 02 Jun, 2006 1 commit
-
-
igor@rurik.mysql.com authored
The bug report revealed two problems related to min/max optimization: 1. If the length of a constant key used in a SARGable condition for for the MIN/MAX fields is greater than the length of the field an unwanted warning on key truncation is issued; 2. If MIN/MAX optimization is applied to a partial index, like INDEX(b(4)) than can lead to returning a wrong result set.
-
- 22 May, 2006 2 commits
-
-
gkodinov@mysql.com authored
Moved the InnoDB related test from func_group.test to innodb_mysql.test
-
msvensson@neptunus.(none) authored
-
- 22 Feb, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
-
- 11 Jan, 2006 1 commit
-
-
evgen@moonbone.local authored
select result Item equal objects are employed only at the optimize phase. Usually they are not supposed to be evaluated. Yet in some cases we call the method val_int() for them. Here we have to take care of restricting the predicate such an object represents f1=f2= ...=fn to the projection of known fields fi1=...=fik. Added a check for field's table being const in Item_equal::val_int(). If the field's table is not const val_int() just skips that field when evaluating Item_equal.
-
- 22 Nov, 2005 1 commit
-
-
ramil@mysql.com authored
-
- 21 Sep, 2005 1 commit
-
-
timour@mysql.com authored
The problem was in that the MIN/MAX optimization in opt_sum_query was replacing MIN/MAX functions with their constant argument without taking into account that a query has no result rows.
-
- 28 Jul, 2005 1 commit
-
-
monty@mysql.com authored
-
- 05 May, 2005 1 commit
-
-
holyfoot@hf-ibm.(none) authored
-
- 23 Mar, 2005 1 commit
-
-
bell@sanja.is.com.ua authored
-
- 20 Mar, 2005 1 commit
-
-
igor@rurik.mysql.com authored
Added a test case for bug #9210. sql_select.cc: Fixed bug #9210. The function calc_group_buffer did not cover the case when the GROUP BY expression was decimal. Slightly optimized the other code.
-
- 15 Mar, 2005 1 commit
-
-
konstantin@mysql.com authored
Item_sum_count_distinct, and deploy Unique for use with COUNT(DISTINCT) if there is no blob column in the list of DISTINCT arguments.
-
- 07 Mar, 2005 3 commits
-
-
hf@deer.(none) authored
-
hf@deer.(none) authored
-
hf@deer.(none) authored
Actually problem was not in AVG function, but in SUM before the AVG in the query.
-
- 05 Mar, 2005 2 commits
-
-
bar@deer.(none) authored
after merge fixes
-
igor@linux.local authored
Logging to logging@openlogging.org accepted func_group.result, func_group.test: Added a test case for bug #8893. opt_sum.cc: A misplaced initialization for the returned parameter prefix_len in the function find_key_for_maxmin caused usage of a wrong key prefix by the min/max optimization in cases when the matching index was not the first index that contained the min/max field.
-
- 01 Mar, 2005 1 commit
-
-
jani@ua141d10.elisa.omakaista.fi authored
-
- 25 Feb, 2005 1 commit
-
-
svoj@mysql.com authored
This bug is also known as WL#1639.
-
- 21 Feb, 2005 1 commit
-
-
hf@deer.(none) authored
-
- 19 Feb, 2005 1 commit
-
-
monty@mysql.com authored
Lots of small fixes to multi-precision-math path Give Note for '123.4e' Added helper functions type 'val_string_from_real() Don't give warnings for end space for string2decimal() Changed storage of values for SP so that we can detect length of argument without strlen() Changed interface for str2dec() so that we must supple the pointer to the last character in the buffer
-
- 04 Feb, 2005 2 commits
-
-
jimw@mysql.com authored
-
gluh@gluh.mysql.r18.ru authored
bug#7833: Wrong datatype of aggregate column is returned
-
- 30 Dec, 2004 1 commit
-
-
sergefp@mysql.com authored
Fix for BUG#7264: Change the test so optimizer doesn't have to make choice between two with [nearly] identical costs.
-
- 07 Dec, 2004 1 commit
-
-
monty@mysql.com authored
Fixed compiler warnings String results in CREATE ... SELECT are now created as CHAR(0), VARCHAR(X) or TEXT() depending on item->max_length
-