mariadb

Commit Graph

Author	SHA1	Message	Date
Oleksandr Byelkin	9b313d2de1	MDEV-32086 Server crash when inserting from derived table containing insert target table Use original solution for INSERT ... SELECT - select result buferisation. Also fix MDEV-36447 and MDEV-33139	7 months ago
Aleksey Midenkov	a96c094d1b	MDEV-25012 Server crash in find_field_in_tables, Assertion `name' failed in find_field_in_table_ref The main crash with segfault in find_field_in_tables() was fixed by `6aa47fae30` (MDEV-35276). This fix is for debug assertion. Since Item_default_value is also Item_field there is nothing to be done except adding DEFAULT_VALUE_ITEM type check.	6 months ago
Jason Cu	2bf9f0d422	MDEV-32395: update_depend_map_for_order: SEGV at /mariadb-11.3.0/sql/sql_select.cc:16583 MDEV-32329 (patch) pushdown from having into where: Server crashes at sub_select When generating an Item_equal with a Item_ref that refers to a field outside of a subselect, remove_item_direct_ref() causes the dependency (depended_from) on the outer select to be lost, which causes trouble for code downstream that can no longer determine the scope of the Item. Not calling remove_item_direct_ref() retains the Item's dependency. Test cases from MDEV-32395 and MDEV-32329 are included. Some fixes from other developers: Monty: - Fixed wrong code in Item_equal::create_pushable_equalities() that could cause wrong item to be used if there was no matching items. Daniel Black: - Added test cases from MDEV-32329 Igor Babaev: - Provided fix for removing call to remove_item_direct_ref() in eliminate_item_equal() MDEV-32395: update_depend_map_for_order: SEGV at /mariadb-11.3.0/sql/sql_select.cc:16583 Include test cases from MDEV-32329.	2 years ago
Oleksandr Byelkin	6aa47fae30	MDEV-35276 Assertion failure in find_producing_item upon a query from a view Two problem solved: 1) Item_default_value makes a shallow copy so the copy should not delete field belong to the Item 2) Item_default_value should not inherit derived_field_transformer_for_having and derived_field_transformer_for_where (in this variant pushing DEFAULT(f) is prohibited (return NULL) but if return "this" it will be allowed (should go with a lot of tests))	12 months ago
Rex	48b256a7e2	MDEV-34506 2nd execution name resolution problem with pushdown into unions Statements affected by this bug need all the following to be true 1) a derived table table or view whose specification contains a set operation at the top level. 2) a grouping operator (group by/having) operating on a column alias other than in the first select of the union/intersect 3) an outer condition that will be pushed into all selects in this union/intersect, either into the where or having clause When pushing a condition into all selects of a unit with more than one select, pushdown_cond_for_derived() renames items so we can re-use the condition being pushed. These names need to be saved and reset for correct name resolution on second execution of prepared statements. Reviewed by Igor Babaev (igor@mariadb.com)	1 year ago
Oleg Smirnov	aae3233c4f	MDEV-34041 Display additional information for materialized subqueries in EXPLAIN/ANALYZE FORMAT=JSON This commits adds the "materialization" block to the output of EXPLAIN/ANALYZE FORMAT=JSON when materialized subqueries are involved into processing. In the case of ANALYZE additional runtime information is displayed, such as: - chosen strategy of materialization - number of partial match/index lookup loops - sizes of partial match buffers	1 year ago
Igor Babaev	b1c8ea83a5	MDEV-32064 Crash when searching for the best split of derived table This bug could affect queries with IN subqueries in WHERE clause and using derived tables to which split optimization potentially could be applied. When looking for the best split of a splittable derived table T any key access from a semi-join materialized table used for lookups S to table T must be excluded from consideration because in the current implementation of such tables as S the values from its records cannot be used to access other tables. Approved by Oleksandr Byelkin <sanja@mariadb.com>	2 years ago
Sergei Petrunia	0ca699bff7	Revert accidentally pushed: commit `e8c9cdc2f8` Author: Sergei Petrunia <sergey@mariadb.com> Date: Wed Oct 11 19:02:25 2023 +0300 MDEV-32301: Server crashes at Arg_comparator::compare_row In Item_bool_rowready_func2::build_clone(): if we're setting clone->cmp.comparators=0 also set const_item_cache=0 as the Item is currently in a state where one cannot compute it.	2 years ago
Sergei Petrunia	e8c9cdc2f8	MDEV-32301: Server crashes at Arg_comparator::compare_row In Item_bool_rowready_func2::build_clone(): if we're setting clone->cmp.comparators=0 also set const_item_cache=0 as the Item is currently in a state where one cannot compute it.	2 years ago
Sergei Petrunia	6e484c3bd9	MDEV-31577: Make ANALYZE FORMAT=JSON print innodb stats ANALYZE FORMAT=JSON output now includes table.r_engine_stats which has the engine statistics. Only non-zero members are printed. Internally: EXPLAIN data structures Explain_table_acccess and Explain_update now have handler* handler_for_stats pointer. It is used to read statistics from handler_for_stats->handler_stats. The following applies only to 10.9+, backport doesn't use it: Explain data structures exist after the tables are closed. We avoid walking invalid pointers using this: - SQL layer calls Explain_query::notify_tables_are_closed() before closing tables. - After that call, printing of JSON output is disabled. Non-JSON output can be printed but we don't access handler_for_stats when doing that.	2 years ago
Sergei Petrunia	2165c30486	Fix testcase for MDEV-31240 to work with --view-protocol.	2 years ago
Igor Babaev	8f3bf593d2	MDEV-31240 Crash with condition pushable into derived and containing outer reference This bug could affect queries containing a subquery over splittable derived tables and having an outer references in its WHERE clause. If such subquery contained an equality condition whose left part was a reference to a column of the derived table and the right part referred only to outer columns then the server crashed in the function st_join_table::choose_best_splitting() The crashing code was added in the commit `ce7ffe61d8` that made the code of the function sensitive to presence of the flag OUTER_REF_TABLE_BIT in the KEYUSE_EXT::needed_in_prefix fields. The field needed_in_prefix of the KEYUSE_EXT structure should not contain table maps with OUTER_REF_TABLE_BIT or RAND_TABLE_BIT. Note that this fix is quite conservative: for affected queries it just returns the query plans that were used before the above mentioned commit. In fact the equalities causing crashes should be pushed into derived tables without any usage of split optimization. Approved by Sergei Petrunia <sergey@mariadb.com>	2 years ago
Sergei Golubchik	c0463704c2	fix the test for --view	2 years ago
Igor Babaev	0474466bc2	MDEV-31240 Crash with condition pushable into derived and containing outer reference This bug could affect queries containing a subquery over splittable derived tables and having an outer references in its WHERE clause. If such subquery contained an equality condition whose left part was a reference to a column of the derived table and the right part referred only to outer columns then the server crashed in the function st_join_table::choose_best_splitting() The crashing code was added in the commit `ce7ffe61d8` that made the code of the function sensitive to presence of the flag OUTER_REF_TABLE_BIT in the KEYUSE_EXT::needed_in_prefix fields. The field needed_in_prefix of the KEYUSE_EXT structure should not contain table maps with OUTER_REF_TABLE_BIT or RAND_TABLE_BIT. Note that this fix is quite conservative: for affected queries it just returns the query plans that were used before the above mentioned commit. In fact the equalities causing crashes should be pushed into derived tables without any usage of split optimization. Approved by Sergei Petrunia <sergey@mariadb.com>	2 years ago
Igor Babaev	5dc9a6b455	MDEV-31102 Crash when pushing condition into view defined as union This bug could manifest itself at the first execution of prepared statement created for queries using a materialized view defined as union. A crash could happen for sure if the query contained a condition pushable into the view and this condition was over the column defined via a complex string expression requiring implicit conversion from one charset to another for some of its sub-expressions. The bug could cause crashes when executing PS for some other queries whose optimization needed building clones for such expressions. This bug was introduced in the patch for MDEV-29988 where the class Item_direct_ref_to_item was added. The implementations of the virtual methods get_copy() and build_clone() were invalid for the class and this could cause crashes after the method build_clone() was called for expressions containing objects of the Item_direct_ref_to_item type. Approved by Sergei Golubchik <serg@mariadb.com>	3 years ago
Igor Babaev	f513d71538	MDEV-30081 Crash with splitting from constant mergeable derived table This bug manifested itself in very rare situations when splitting optimization was applied to a materialized derived table with group clause by key over a constant meargeable derived table that was in inner part of an outer join. In this case the used tables for the key to access the split table incorrectly was evaluated to a not empty table map. Approved by Oleksandr Byelkin <sanja@mariadb.com>	3 years ago
Michael Widenius	432a4ebe5c	Improve table pruning in optimizer with up to date key_dependent map Part of: MDEV-28073 Slow query performance in MariaDB when using many tables s->key_dependent has a list of tables that are compared with key fields in the current table. However it does not take into account if a key field could be resolved by another table. This is because MariaDB expands 'join_tab->keyuse' to include all generated comparisons. For example: SELECT * from t1,t2,t3 where t1.key=t2.key and t2.key=t3.key In this case keyuse for t1 includes t2.key and t3.key and key_dependent contains 't2.map \| t3.map' If we in best_extension_by_limited_search() consider t2,t1 then t1's key is fully defined, but we cannot do any prune of plans as s->key_dependent indicates that t3 is still needed. Fixed by calculating in best_access_patch the current key_dependent map of tables that is needed to satisfy all keys. This allows us to prune more bad plans earlier as soon as all keys can be used. We also set key_dependent to 0 if we found an EQ_REF key, as this an optimal key for the table and there is no reason to check more keys.	3 years ago
Michael Widenius	64f24b776d	greedy_search() and best_extension_by_limited_search() scrambled table order best_extension_by_limited_search() assumes that tables should be sorted according to size to be able to quickly disregard bad plans. However the current usage of swap_variables() will change the table order to a not sorted one for the next recursive call. This breaks the assumtion and causes performance issues when using many tables (we have to examine many more plans). This patch fixes this by ensuring that the original table order is kept for the not yet used tables when best_extension_by_limited_search() is called. This was done by always calling swap_variables() for each table and restoring the original table order at exit. Some test changed: - In a majority of the test the change was that two "identical tables" where swapped and the optimzer is now using the first/smaller table - In few test the table order was changed. The new plan looks identical or slighly better than the original.	3 years ago
Oleg Smirnov	7498978e6a	MDEV-27699 ANALYZE FORMAT=JSON fields are incorrect for UNION ALL queries UNION ALL queries are a subject of optimization introduced in MDEV-334 when creation of a temporary table is skipped. While there is a check for this optimization in Explain_union::print_explain() there was no such in Explain_union::print_explain_json(). This resulted in printing irrelevant data like: "union_result": { "table_name": "<union2,3>", "access_type": "ALL", "r_loops": 0, "r_rows": null in case when creation of the temporary table was actually optimized out. This commits adds a check whether the temporary table was actually created during the UNION ALL processing and eliminates printing of the irrelevant data.	4 years ago
Igor Babaev	0041265671	MDEV-27510 Query returns wrong result when using split optimization This bug may affect the queries that uses a grouping derived table with grouping list containing references to columns from different tables if the optimizer decides to employ the split optimization for the derived table. In some very specific cases it may affect queries with a grouping derived table that refers only one base table. This bug was caused by an improper fix for the bug MDEV-25128. The fix tried to get rid of the equality conditions pushed into the where clause of the grouping derived table T to which the split optimization had been applied. The fix erroneously assumed that only those pushed equalities that were used for ref access of the tables referenced by T were needed. In fact the function remove_const() that figures out what columns from the group list can be removed if the split optimization is applied can uses other pushed equalities as well. This patch actually provides a proper fix for MDEV-25128. Rather than trying to remove invalid pushed equalities referencing the fields of SJM tables with a look-up access the patch attempts not to push such equalities. Approved by Oleksandr Byelkin <sanja@mariadb.com>	4 years ago
Igor Babaev	97425f740f	MDEV-27132 Wrong result from query when using split optimization This bug could affect queries with a grouping derived table containing equalities in the where clause of its specification if the optimizer chose to apply split optimization to access the derived table. In such cases wrong results could be returned from the queries. When the optimizer considers a possibility of using split optimization to a derived table it injects equalities joining the derived table with other tables into the where condition of the derived table. After the join order for the execution using split optimization has been chosen as the cheapest the injected equalities that are not used to access the derived table are removed from the where condition of the derived table. For this removal the optimizer looks through the conjuncts of the where condition of the derived table, fetches the equalities and checks whether they belong to the list of injected equalities. As the injection of the list was performed just by the insertion of it into the list of top level AND condition of the where condition some extra conjuncts from the where condition could be automatically attached to the end of the list of injected equalities. If such attached conjunct happened to be an equality predicate it was removed from the where condition of the derived table and thus lost for checking at the execution phase. The bug has been fixed by injecting of a shallow copy of the list of the pushed equalities rather than the list itself leaving the latter intact. Approved by Oleksandr Byelkin <sanja@mariadb.com>	4 years ago
Sergei Petrunia	c7443a0911	MDEV-25969: Condition pushdown into derived table doesn't work if select list uses SP Post-merge fix in 10.4: add a testcase for pushdown into IN subquery	4 years ago
Sergei Petrunia	4a6e2d3437	Post-merge fix: update derived_cond_pushdown.result	4 years ago
Igor Babaev	0b797130c6	MDEV-25714 Join using derived with aggregation returns incorrect results If a join query uses a derived table (view / CTE) with GROUP BY clause then the execution plan for such join may employ split optimization. When this optimization is employed the derived table is not materialized. Rather only some partitions of the derived table are subject to grouping. Split optimization can be applied only if: - there are some indexes over the tables used in the join specifying the derived table whose prefixes partially cover the field items used in the GROUP BY list (such indexes are called splitting indexes) - the WHERE condition of the join query contains conjunctive equalities between columns of the derived table that comprise major parts of splitting indexes and columns of the other join tables. When the optimizer evaluates extending of a partial join by the rows of the derived table it always considers a possibility of using split optimization. Different splitting indexes can be used depending on the extended partial join. At some rare conditions, for example, when there is a non-splitting covering index for a table joined in the join specifying the derived table usage of a splitting index to produce rows needed for grouping may be still less beneficial than usage of such covering index without any splitting technique. The function JOIN_TAB::choose_best_splitting() must take this into account. Approved by Oleksandr Byelkin <sanja@mariadb.com>	4 years ago
Igor Babaev	663bc849b5	MDEV-25714 Join using derived with aggregation returns incorrect results If a join query uses a derived table (view / CTE) with GROUP BY clause then the execution plan for such join may employ split optimization. When this optimization is employed the derived table is not materialized. Rather only some partitions of the derived table are subject to grouping. Split optimization can be applied only if: - there are some indexes over the tables used in the join specifying the derived table whose prefixes partially cover the field items used in the GROUP BY list (such indexes are called splitting indexes) - the WHERE condition of the join query contains conjunctive equalities between columns of the derived table that comprise major parts of splitting indexes and columns of the other join tables. When the optimizer evaluates extending of a partial join by the rows of the derived table it always considers a possibility of using split optimization. Different splitting indexes can be used depending on the extended partial join. At some rare conditions, for example, when there is a non-splitting covering index for a table joined in the join specifying the derived table usage of a splitting index to produce rows needed for grouping may be still less beneficial than usage of such covering index without any splitting technique. The function JOIN_TAB::choose_best_splitting() must take this into account. Approved by Oleksandr Byelkin <sanja@mariadb.com>	4 years ago
Igor Babaev	480a06718d	MDEV-25128 Wrong result from join with materialized semi-join and splittable derived If one of joined tables of the processed query is a materialized derived table (or view or CTE) with GROUP BY clause then under some conditions it can be subject to split optimization. With this optimization new equalities are injected into the WHERE condition of the SELECT that specifies this derived table. The injected equalities are generated for all join orders with which the split optimization can employed. After the best join order has been chosen only certain of this equalities are really needed. The others can be safely removed. If it's not done and some of injected equalities involve expressions over semi-joins with look-up access then the query may return a wrong result set. This patch effectively removes equalities injected for split optimization that are needed only at the optimization stage and not needed for execution. Approved by serg@mariadb.com	5 years ago
Varun Gupta	1be707286e	Added the test case for MDEV-23804	5 years ago
Sergei Petrunia	d01d94d77b	MDEV-17568: LATERAL DERIVED is not clearly visible in EXPLAIN FORMAT=JSON Make LATERAL DERIVED tables visible in EXPLAIN FORMAT=JSON output.	6 years ago
Monty	27d9986c1b	Added more digits to JSON output of double sprintf() format of double changed from '%lg' to '%-.11lg' The change was to make it easier to read optimizer trace output with tables that has millions of records.	6 years ago
Monty	eb483c5181	Updated optimizer costs in multi_range_read_info_const() and sql_select.cc - multi_range_read_info_const now uses the new records_in_range interface - Added handler::avg_io_cost() - Don't calculate avg_io_cost() in get_sweep_read_cost if avg_io_cost is not 1.0. In this case we trust the avg_io_cost() from the handler. - Changed test_quick_select to use TIME_FOR_COMPARE instead of TIME_FOR_COMPARE_IDX to align this with the rest of the code. - Fixed bug when using test_if_cheaper_ordering where we didn't use keyread if index was changed - Fixed a bug where we didn't use index only read when using order-by-index - Added keyread_time() to HEAP. The default keyread_time() was optimized for blocks and not suitable for HEAP. The effect was the HEAP prefered table scans over ranges for btree indexes. - Fixed get_sweep_read_cost() for HEAP tables - Ensure that range and ref have same cost for simple ranges Added a small cost (MULTI_RANGE_READ_SETUP_COST) to ranges to ensure we favior ref for range for simple queries. - Fixed that matching_candidates_in_table() uses same number of records as the rest of the optimizer - Added avg_io_cost() to JT_EQ_REF cost. This helps calculate the cost for HEAP and temporary tables better. A few tests changed because of this. - heap::read_time() and heap::keyread_time() adjusted to not add +1. This was to ensure that handler::keyread_time() doesn't give higher cost for heap tables than for normal tables. One effect of this is that heap and derived tables stored in heap will prefer key access as this is now regarded as cheap. - Changed cost for index read in sql_select.cc to match multi_range_read_info_const(). All index cost calculation is now done trough one function. - 'ref' will now use quick_cost for keys if it exists. This is done so that for '=' ranges, 'ref' is prefered over 'range'. - scan_time() now takes avg_io_costs() into account - get_delayed_table_estimates() uses block_size and avg_io_cost() - Removed default argument to test_if_order_by_key(); simplifies code	6 years ago
Igor Babaev	caf110fa52	MDEV-21883 Server crashes when joining a subselect with 32 tables and GROUP BY This bug could cause a crash for any query that used a derived table/view/CTE whose specification was a SELECT with a GROUP BY clause and a FROM list containing 32 or more table references. The problem appeared only in the cases when the splitting optimization could be applied to such derived table/view/CTE.	6 years ago
Igor Babaev	8d7462ec49	MDEV-21614 Wrong query results with optimizer_switch="split_materialized=on" Do not materialize a semi-join nest if it contains a materialized derived table /view that potentially can be subject to the split optimization. Splitting of materialization of such nest would help, but currently there is no code to support this technique.	6 years ago
Igor Babaev	1c97cd339e	MDEV-21184 Assertion `used_tables_cache == 0' failed in Item_func::fix_fields with condition_pushdown_from_having This bug could manifest itself for queries with GROUP BY and HAVING clauses when the HAVING clause was a conjunctive condition that depended exclusively on grouping fields and at least one conjunct contained an equality of the form fld=sq where fld is a grouping field and sq is a constant subquery. In this case the optimizer tries to perform a pushdown of the HAVING condition into WHERE. To construct the pushable condition the optimizer first transforms all multiple equalities in HAVING into simple equalities. This has to be done for a proper processing of the pushed conditions in WHERE. The multiple equalities at all AND/OR levels must be converted to simple equalities because any multiple equality may refer to a multiple equality at the upper level. Before this patch the conversion was performed like this: multiple_equality(x,f1,...,fn) => x=f1 and ... and x=fn. When an equality item for x=fi was constructed both the items for x and fi were cloned. If x happened to be a constant subquery that could not be cloned the conversion failed. If the conversions of multiple equalities previously performed had succeeded then the whole condition became in an inconsistent state that could cause different failures. The solution provided by the patch is: 1. to use a different conversion rule if x is a constant multiple_equality(x,f1,...,fn) => f1=x and f2=f1 and ... and fn=f1 2. not to clone x if it's a constant. Such conversions cannot fail and besides the result of the conversion preserves the equivalence of f1,...,fn that can be used for other optimizations. This patch also made sure that expensive predicates are not pushed from HAVING to WHERE.	6 years ago
Alexander Barkov	462d689397	MDEV-19468 Hybrid type expressions return wrong format for FLOAT	7 years ago
Galina Shalygina	ae15f91f22	MDEV-18769 Assertion `fixed == 1' failed in Item_cond_or::val_int This bug is caused by pushdown from HAVING into WHERE. It appears because condition that is pushed wasn't fixed. It is also discovered that condition pushdown from HAVING into WHERE is done wrong. There is no need to build clones for some conditions that can be pushed. They can be simply moved from HAVING into WHERE without cloning. build_pushable_cond_for_having_pushdown(), remove_pushed_top_conjuncts_for_having() methods are changed. It is found that there is no transformation made for fields of pushed condition. field_transformer_for_having_pushdown transformer is added. New tests are added. Some comments are changed.	7 years ago
Igor Babaev	9bd47835d0	MDEV-18679 Server crashes in JOIN::optimize The bug manifested itself when executing a query with materialized view/derived/CTE whose specification was a SELECT query contained another materialized derived and impossible WHERE/HAVING condition was detected for this SELECT. As soon as such condition is detected the join structures of all derived tables used in the SELECT are destroyed. So optimization of the queries specifying these derived tables is impossible. Besides it's not needed. In 10.3 optimization of a materialized derived table is performed before detection of impossible WHERE/HAVING condition in the embedding SELECT.	7 years ago
Varun Gupta	d6db6df995	MDEV-17903: New optimizer defaults: change optimize_join_buffer_size to be ON optimize_join_buffer_size is switched ON.	7 years ago
Galina Shalygina	9741930490	MDEV-18636 The test case for bug mdev-16765 crashes the server in the tree bb-10.4-mdev7486 The crash was caused because of the similar problem as in mdev-16765: Item_cond::excl_dep_on_group_fields_for_having_pushdown() was missing.	7 years ago
Sergei Petrunia	15a77a1a2c	MDEV-18608: Defaults for 10.4: histogram size should be set Change the defaults: -histogram_size=0 +histogram_size=254 -histogram_type=SINGLE_PREC_HB +histogram_type=DOUBLE_PREC_HB Adjust the testcases: - Some have ignorable changes in EXPLAIN outputs and more counter increments due to EITS table reads. - Testcases that meaningfully depend on the old defaults are changed to use the old values.	7 years ago
Galina Shalygina	7a77b221f1	MDEV-7486: Condition pushdown from HAVING into WHERE 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.	7 years ago
Igor Babaev	658128af43	MDEV-16188 Use in-memory PK filters built from range index scans 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 `8d5a11122c`. 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.	7 years ago
Varun Gupta	93c360e3a5	MDEV-15253: Default optimizer setting changes for MariaDB 10.4 use_stat_tables= PREFERABLY optimizer_use_condition_selectivity= 4	7 years ago
Igor Babaev	c2c1550f57	MDEV-17419 Subquery with group by returns wrong results Added only test case because the bug was fixed by the patch for mdev-17382.	7 years ago
Igor Babaev	d453374fc4	MDEV-16801 seg_fault on a query The bug was in the in the code of JOIN::check_for_splittable_materialized() where the structures describing the fields of a materialized derived table that potentially could be used in split optimization were build. As a result of this bug some fields that were not usable for splitting were detected as usable. This could trigger crashes further in st_join_table::choose_best_splitting().	7 years ago
Oleksandr Byelkin	de745ecf29	MDEV-11953: support of brackets in UNION/EXCEPT/INTERSECT operations	8 years ago
Igor Babaev	fc0f5adb7f	MDEV-16104 Server crash in JOIN::fix_all_splittings_in_plan upon select with view and subqueries This bug occurred when a splittable materialized derived/view were used inside another splittable materialized derived/view. The bug happened because the function JOIN::fix_all_splittings_in_plan() was called at the very beginning of the optimization phase 2 at the moment when the plan structure of the embedding derived/view were not valid. The proper position for this call is the very end of the optimization phase 1.	8 years ago
Varun Gupta	724ab9a1cb	MDEV-16057: Using optimization Splitting with Group BY we see an unnecessary attached condition t1.pk IS NOT NULL where pk is a PRIMARY KEY For equalites in the WHERE clause we create a keyuse array that contains the set of all equalities. For each KEYUSE inside the keyuse array we have a field "null_rejecting" which tells that the equality will not hold if either the left or right hand side of the equality is NULL. If the equality is NULL rejecting then we accordingly add a NOT NULL condition for the field present in the item val(present in the KEYUSE struct) when we are doing ref access. For the optimization of splitting with GROUP BY we always set the null_rejecting to TRUE and we are doing ref access on the GROUP by field. This does create a problem when the equality is NOT NULL rejecting. This happens in this case as in the equality we have the right hand side as t1.pk where pk is a PRIMARY KEY , hence it is NOT NULLABLE. So we should have null rejecting set to FALSE for such a case.	8 years ago
Igor Babaev	615ad709a3	MDEV-15902 Assertion `n < m_size' failed, sql_array.h:64: Element_type& Bounds_checked_array<Element_type>::operator[] (size_t) [with Element_type = Item*; size_t = long unsigned int] In sql_yacc.yy the semantic actions for the MEDIAN window function lacked a call of st_select_lex::prepare_add_window_spec(). This function saves the head of the thd->lex->order_list into lex->save_order_list in order this head to be restored in st_select_lex::add_window_spec after the specification of the window function has been parsed. Without a call of prepare_add_window_spec() when add_window_spec() was called the head of an empty list was copied into thd->lex->order_list (instead of assumed saved head this list). This made the list thd->lex->order_list invalid and potentially could cause many different problems. Corrected the result set in the test case for MDEV-15899 that used the MEDIAN window function and could not be correct without this fix.	8 years ago
Igor Babaev	cff60be7fe	MDEV-15899 Server crashes in st_join_table::is_inner_table_of_outer_join The crash happened because JOIN::check_for_splittable_materialized() called by mistake the function JOIN_TAB::is_inner_table_of_outer_join() instead of the function TABLE_LIST::is_inner_table_of_outer_join(). The former cannot be called before the call of make_outerjoin_info().	8 years ago
Sergei Golubchik	c43a0e0a77	bugfix: Item_cache_temporal::convert_to_basic_const_item assumed DATETIME this is a 10.3 version of `1c6f6dc892`	8 years ago

1 2 3

120 Commits (19644f6821d59ecca0f9b1f44fadb3b887061965)