An error occurred fetching the project authors.
- 17 Nov, 2009 1 commit
-
-
Evgeny Potemkin authored
MySQL manual describes values of the YEAR(2) field type as follows: values 00 - 69 mean 2000 - 2069 years and values 70 - 99 mean 1970 - 1999 years. MIN/MAX and comparison functions was comparing them as int values thus producing wrong result. Now the Arg_comparator class is extended with compare_year function which performs correct comparison of the YEAR type. The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to correctly calculate its value. To allow Arg_comparator to use func_name() function for Item_func and Item_sum objects the func_name declaration is moved to the Item_result_field class. A helper function is_owner_equal_func is added to the Arg_comparator class. It checks whether the Arg_comparator object owner is the <=> function or not. A helper function setup is added to the Item_sum_hybrid class. It sets up cache item and comparator.
-
- 14 Oct, 2009 1 commit
-
-
Jorgen Loland authored
columns without where/group Simple SELECT with implicit grouping used to return many rows if the query was ordered by the aggregated column in the SELECT list. This was incorrect because queries with implicit grouping should only return a single record. The problem was that when JOIN:exec() decided if execution needed to handle grouping, it was assumed that sum_func_count==0 meant that there were no aggregate functions in the query. This assumption was not correct in JOIN::exec() because the aggregate functions might have been optimized away during JOIN::optimize(). The reason why queries without ordering behaved correctly was that sum_func_count is only recalculated if the optimizer chooses to use temporary tables (which it does in the ordered case). Hence, non-ordered queries were correctly treated as grouped. The fix for this bug was to remove the assumption that sum_func_count==0 means that there is no need for grouping. This was done by introducing variable "bool implicit_grouping" in the JOIN object.
-
- 01 Apr, 2009 1 commit
-
-
Gleb Shchepa authored
Original commentary: Bug #37348: Crash in or immediately after JOIN::make_sum_func_list The optimizer pulls up aggregate functions which should be aggregated in an outer select. At some point it may substitute such a function for a field in the temporary table. The setup_copy_fields function doesn't take this into account and may overrun the copy_field buffer. Fixed by filtering out the fields referenced through the specialized reference for aggregates (Item_aggregate_ref). Added an assertion to make sure bugs that cause similar discrepancy don't go undetected.
-
- 28 Jan, 2009 1 commit
-
-
Alexey Kopytov authored
Various parts of code used different 'precision' arguments for sprintf("%g") when converting floating point numbers to a string. This led to differences in results in some cases depending on whether the text-based or prepared statements protocol is used for a query. Fixed by changing arguments to sprintf("%g") to always be 15 (DBL_DIG) so that results are consistent regardless of the protocol. This patch will be null-merged to 6.0 as the problem does not exists there (fixed by the patch for WL#2934).
-
- 24 Nov, 2008 1 commit
-
-
Georgi Kodinov authored
ONLY_FULL_GROUP_BY The check for non-aggregated columns in queries with aggregate function, but without GROUP BY was treating all the parts of the query as if they are in the SELECT list. Fixed by ignoring the non-aggregated fields in the WHERE clause.
-
- 02 Oct, 2008 1 commit
-
-
Georgi Kodinov authored
The optimizer pulls up aggregate functions which should be aggregated in an outer select. At some point it may substitute such a function for a field in the temporary table. The setup_copy_fields function doesn't take this into account and may overrun the copy_field buffer. Fixed by filtering out the fields referenced through the specialized reference for aggregates (Item_aggregate_ref). Added an assertion to make sure bugs that cause similar discrepancy don't go undetected.
-
- 06 Mar, 2008 1 commit
-
-
kaa@kaamos.(none) authored
returns wrong results Casting AVG() to DECIMAL led to incorrect results when the arguments had a non-DECIMAL type, because in this case Item_sum_avg::val_decimal() performed the division by the number of arguments twice. Fixed by changing Item_sum_avg::val_decimal() to not rely on Item_sum_sum::val_decimal(), i.e. calculate sum and divide using DECIMAL arithmetics for DECIMAL arguments, and utilize val_real() with subsequent conversion to DECIMAL otherwise.
-
- 09 Jan, 2008 2 commits
-
-
gkodinov/kgeorge@macbook.gmz authored
-
gkodinov/kgeorge@macbook.gmz authored
When resolving references we need to take into consideration the view "fields" and allow qualified access to them. Fixed by extending the reference resolution to process view fields correctly.
-
- 01 Nov, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
The HAVING clause is subject to the same rules as the SELECT list about using aggregated and non-aggregated columns. But this was not enforced when processing implicit grouping from using aggregate functions. Fixed by performing the same checks for HAVING as for SELECT.
-
- 24 Oct, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
file .\opt_sum.cc, line The optimizer pre-calculates the MIN/MAX values for queries like SELECT MIN(kp_k) WHERE kp_1 = const AND ... AND kp_k-1 = const when there is a key over kp_1...kp_k In doing so it was not checking correctly nullability and there was a superfluous assert(). Fixed by making sure that the field can be null before checking and taking out the wrong assert(). . Introduced a correct check for nullability The MIN(field) can return NULL when all the row values in the group are NULL-able or if there were no rows. Fixed the assertion to reflect the case when there are no rows.
-
- 08 Oct, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
Item_sum_distinct::setup(THD*): Assertion There was an assertion to detect a bug in ROLLUP implementation. However the assertion is not true when used in a subquery context with non-cacheable statements. Fixed by turning the assertion to accepted case (just like it's done for the other aggregate functions).
-
- 29 May, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
- Renamed "Using join cache" to "Using join buffer". - "Using join buffer" is now printed on the last table that "reads" from the join buffer cache.
-
- 15 May, 2007 1 commit
-
-
mhansson/martin@linux-st28.site authored
to NULL For queries of the form SELECT MIN(key_part_k) FROM t1 WHERE key_part_1 = const and ... and key_part_k-1 = const, the opt_sum_query optimization tries to use an index to substitute MIN/MAX functions with their values according to the following rules: 1) Insert the minimum non-null values where the WHERE clause still matches, or 3) A row of nulls However, the correct semantics requires that there is a third case 2) such that a NULL value is substituted if there are only NULL values for key_part_k. The patch modifies opt_sum_query() to handle this missing case.
-
- 04 May, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
- added join cache indication in EXPLAIN (Extra column). - prefer filesort over full scan over index for ORDER BY (because it's faster). - when switching from REF to RANGE because RANGE uses longer key turn off sort on the head table only as the resulting RANGE access is a candidate for join cache and we don't want to disable it by sorting on the first table only.
-
- 27 Feb, 2007 1 commit
-
-
Round the results of std() for some calls with double arguments to avoid double math precision problems.
-
- 26 Dec, 2006 1 commit
-
-
tsmith/tim@siva.hindu.god authored
In func_group.test, round the results of std() for some calls, because Windows' sqrt() function appears to return fewer "significant" digits than the Unix implementations. This is for bug #22555.
-
- 22 Dec, 2006 2 commits
-
-
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.
-
We use val_int() calls (followed by null_value check) to determine nullness in some Item_sum_count' and Item_sum_count_distinct' methods, as a side effect we get extra warnings raised in the val_int(). Fix: use is_null() instead.
-
- 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.
-