summaryrefslogtreecommitdiff
path: root/mysql-test/main/select.result
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch '10.3' into 10.4Oleksandr Byelkin2019-05-191-7/+7
|\
| * MDEV-19468 Hybrid type expressions return wrong format for FLOATAlexander Barkov2019-05-151-7/+7
| |
* | MDEV-13628: ORed condition in pushed index condition is not removed from the ↵Varun Gupta2019-05-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WHERE So to push index condition for each join tab we have calculate the index condition that can be pushed and then remove this index condition from the original condition. This is done through the function make_cond_remainder. The problem is the function make_cond_remainder does not remove index condition when there is an OR operator. Fixed this by making the function make_cond_remainder to keep in mind of the OR operator. Also updated results for multiple test files which were incorrectly updated by the commit e0c1b3f24246d22e6785315f9a8448bd9a590422 code which was supposed to remove the condition present in the index condition was not getting executed when the condition had OR operator, with AND the pushed index condition was getting removed from where. This problem affects all versions starting from 5.5 but this is a performance improvement, so fixing it in 10.4
* | MDEV-7486: Condition pushdown from HAVING into WHEREGalina Shalygina2019-02-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Condition can be pushed from the HAVING clause into the WHERE clause if it depends only on the fields that are used in the GROUP BY list or depends on the fields that are equal to grouping fields. Aggregate functions can't be pushed down. How the pushdown is performed on the example: SELECT t1.a,MAX(t1.b) FROM t1 GROUP BY t1.a HAVING (t1.a>2) AND (MAX(c)>12); => SELECT t1.a,MAX(t1.b) FROM t1 WHERE (t1.a>2) GROUP BY t1.a HAVING (MAX(c)>12); The implementation scheme: 1. Extract the most restrictive condition cond from the HAVING clause of the select that depends only on the fields that are used in the GROUP BY list of the select (directly or indirectly through equalities) 2. Save cond as a condition that can be pushed into the WHERE clause of the select 3. Remove cond from the HAVING clause if it is possible The optimization is implemented in the function st_select_lex::pushdown_from_having_into_where(). New test file having_cond_pushdown.test is created.
* | MDEV-16188 Introduced the notion of adjusted filter gain.Igor Babaev2019-02-141-4/+4
| | | | | | | | | | | | Due to inconsistent usage of different cost models to calculate the cost of ref accesses we have to make the calculation of the gain promising by usage a range filter more complex.
* | MDEV-16188 Post merge fixes:fixed warnings on WindowsIgor Babaev2019-02-061-3/+3
| | | | | | | | Also adjusted some result files after Galina's last patch for ANALYZE.
* | Fixed the results after the merge of 10.4 into bb-10.4-mdev16188.Igor Babaev2019-02-031-0/+1
| |
* | Merge branch '10.4' into bb-10.4-mdev16188Igor Babaev2019-02-031-0/+3
|\ \
| * | MDEV-15253: Default optimizer setting changes for MariaDB 10.4Varun Gupta2018-12-091-0/+3
| | | | | | | | | | | | | | | use_stat_tables= PREFERABLY optimizer_use_condition_selectivity= 4
* | | MDEV-16188 Use in-memory PK filters built from range index scansIgor Babaev2019-02-031-27/+68
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains a full implementation of the optimization that allows to use in-memory rowid / primary filters built for range   conditions over indexes. In many cases usage of such filters reduce   the number of disk seeks spent for fetching table rows. In this implementation the choice of what possible filter to be applied   (if any) is made purely on cost-based considerations. This implementation re-achitectured the partial implementation of the feature pushed by Galina Shalygina in the commit 8d5a11122c32f4d9eb87536886c6e893377bdd07. Besides this patch contains a better implementation of the generic   handler function handler::multi_range_read_info_const() that takes into account gaps between ranges when calculating the cost of range index scans. It also contains some corrections of the implementation of the handler function records_in_range() for MyISAM. This patch supports the feature for InnoDB and MyISAM.
* | MDEV-17563 Different results using table or view when comparing values of ↵Alexander Barkov2018-11-081-16/+16
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | time type MDEV-17625 Different warnings when comparing a garbage to DATETIME vs TIME - Splitting processes of data type conversion (to TIME/DATE,DATETIME) and warning generation. Warning are now only get collected during conversion (in an "int" variable), and are pushed in the very end of conversion (not in parallel). Warnings generated by the low level routines str_to_xxx() and number_to_xxx() can now be changed at the end, when TIME_FUZZY_DATES is applied, from "Invalid value" to "Truncated invalid value". Now "Illegal value" is issued only when the low level routine returned an error and TIME_FUZZY_DATES was not set. Otherwise, if the low level routine returned "false" (success), or if NULL was converted to a zero datetime by TIME_FUZZY_DATES, then "Truncated illegal value" is issued. This gives better warnings. - Methods Type_handler::Item_get_date() and Type_handler::Item_func_hybrid_field_type_get_date() now only convert and collect warning information, but do not push warnings. - Changing the return data type for Type_handler::Item_get_date() and Type_handler::Item_func_hybrid_field_type_get_date() from "bool" to "void". The conversion result (success vs error) can be checked by testing ltime->time_type. MYSQL_TIME_{NONE|ERROR} mean mean error, other values mean success. - Adding new wrapper methods Type_handler::Item_get_date_with_warn() and Type_handler::Item_func_hybrid_field_type_get_date_with_warn() to do conversion followed by raising warnings, and changing the code to call new Type_handler::***_with_warn() methods. - Adding a helper class Temporal::Status, a wrapper for MYSQL_TIME_STATUS with automatic initialization. - Adding a helper class Temporal::Warn, to collect warnings but without actually raising them. Moving a part of ErrConv into a separate class ErrBuff, and deriving both Temporal::Warn and ErrConv from ErrBuff. The ErrBuff part of Temporal::Warn is used to collect textual representation of the input data. - Adding a helper class Temporal::Warn_push. It's used to collect warning information during conversion, and automatically pushes warnings to the diagnostics area on its destructor time (in case of non-zero warning). - Moving more code from various functions inside class Temporal. - Adding more Temporal_hybrid constructors and protected Temporal methods make_from_xxx(), which convert and only collect warning information, but do not actually raise warnings. - Now the low level functions str_to_datetime() and str_to_time() always set status->warning if the return value is "true" (error). - Now the low level functions number_to_time() and number_to_datetime() set the "*was_cut" argument if the return value is "true" (error). - Adding a few DBUG_ASSERTs to make sure that str_to_xxx() and number_to_xxx() always set warnings on error. - Adding new warning flags MYSQL_TIME_WARN_EDOM and MYSQL_TIME_WARN_ZERO_DATE for the code symmetry. Before this change there was a special code path for (rc==true && was_cut==0) which was treated by Field_temporal::store_invalid_with_warning as "zero date violation". Now was_cut==0 always means that there are no any error/warnings/notes to be raised, not matter what rc is. - Using new Temporal_hybrid constructors in combination with Temporal::Warn_push inside str_to_datetime_with_warn(), double_to_datetime_with_warn(), int_to_datetime_with_warn(), Field::get_date(), Item::get_date_from_string(), and a few other places. - Removing methods Dec_ptr::to_datetime_with_warn(), Year::to_time_with_warn(), my_decimal::to_datetime_with_warn(), Dec_ptr::to_datetime_with_warn(). Fixing Sec6::to_time() and Sec6::to_datetime() to convert and only collect warnings, without raising warnings. Now warning raising functionality resides in Temporal::Warn_push. - Adding classes Longlong_hybrid_null and Double_null, to return both value and the "IS NULL" flag. Adding methods Item::to_double_null(), to_longlong_hybrid_null(), Item_func_hybrid_field_type::to_longlong_hybrid_null_op(), Item_func_hybrid_field_type::to_double_null_op(). Removing separate classes VInt and VInt_op, as they have been replaced by a single class Longlong_hybrid_null. - Adding a helper method Temporal::type_name_by_timestamp_type(), moving a part of make_truncated_value_warning() into it, and reusing in Temporal::Warn::push_conversion_warnings(). - Removing Item::make_zero_date() and Item_func_hybrid_field_type::make_zero_mysql_time(). They provided duplicate functionality. Now this code resides in Temporal::make_fuzzy_date(). The latter is now called for all Item types when data type conversion (to DATE/TIME/DATETIME) is involved, including Item_field and Item_direct_view_ref. This fixes MDEV-17563: Item_direct_view_ref now correctly converts NULL to a zero date when TIME_FUZZY_DATES says so.
* Create 'main' test directory and move 't' and 'r' thereMichael Widenius2018-03-291-0/+5550