- 03 11月, 2022 1 次提交
-
-
由 lihongjian 提交于
fix 1:#818 Master slave synchronization - There will be too many tuples problem Cause: Tianmu::dbhandler::TianmuHandler::current_position This variable is not initialized. In some cases, a large value may cause too many tuples problem. Solution: Initialize the variable fix 2:#819 Master slave synchronization - Primary key conflict problem Solution: Modify the modification logic of master slave synchronization, so that the delete and update operations do not follow the primary key logic Supplement sql/sql_insert.cc Fix the problem that the insert statement will not generate binlog in the delayed insert mode storage/tianmu/handler/tianmu_handler.cpp Fix the binlog error of the line format generated by the tianmu engine
-
- 23 10月, 2022 1 次提交
-
-
由 悟世者 提交于
fix(tianmu): Fixed tianmu syntax compatibility issue when continuous equivalent predicates are eliminated (#733) The root cause is that the tianmu syntax tree conversion cannot support continuous null-value elimination, and the cleaned equal-value elimination items are retained to be compatible with the tianmu execution plan
-
- 21 10月, 2022 2 次提交
-
-
由 悟世者 提交于
The cause of an error is that you need to identify the returned result of the exists subquery for sl->join->zero_result_cause Determines whether a return value exists. and format query.cpp : The exists subquery determines whether a value exists during the query optimization phase result is not set to zero only when a matching value is found in the query optimization phase When a field has an index, the optimization phase scans the table through the index The primary key implementation of the current column storage engine has a problem with the primary key index to scan the table for data As a result, the primary key index is used to obtain the exists subquery result in the query optimization phase. Therefore, the exists subquery is not executed in the query execution phase scan the table for data Remove the following temporary practices after primary key indexing is complete
-
由 悟世者 提交于
replace always true for examples: select * from t1 where b>2 or 1=2; select * from t1 where b>2 or 1<2; select * from t1 where b>2 or 1>2; select * from t1 where b>2 or 1=1; select * from t1 where b>2 or 1; select * from t1 where b>2 or 0; select * from t1 where ((((1=1) or (3=3)) and (3=3)) or ((1=100) and (5=a))); select * from t1 where ((((1=1) or (3=3)) and (3=4)) or ((1=100) and (5=a))); select * from t1 where ((((1=2) or (3=3)) and (3=3)) or ((1=100) and (5=a))); select * from t1 where ((((1>2) or (3=3)) and (3=3)) or ((1=1) and (5=a))); select * from t1 where ((((1=2) or (3<3)) and (3=3)) or ((1=1) and (5=a))); select * from t1 where ((((1=2) or (3<3)) and (3>1)) or ((1=1) and (5=a))); select * from t1 where ((((1=2) or (3=3)) and (3=1)) or ((1>1) and (5=a)));
-
- 20 10月, 2022 2 次提交
-
-
由 lihongjian 提交于
-
由 lihongjian 提交于
Cause: At present, the primary key of the tianmu engine does not fully support delete and update statements. Temporary solution: Modify the execution plan of the SQL layer so that the delete and update statements do not follow the primary key logic
-
- 18 10月, 2022 2 次提交
-
-
由 悟世者 提交于
fix issuse 468 461 mtr result
-
由 悟世者 提交于
The reason for the error lies in that in Item_cond_or condition, sub-conditions similar to a=a will be cleared after elimination of equivalent conditions, but the tianmu engine does not do additional scene processing for the remaining conditions after elimination of equivalent conditions of Item_cond_or. Results in a scenario where only the remaining predicates are processed and the or predicates are not considered. The corresponding issuse: https://github.com/stoneatom/stonedb/issues/301 https://github.com/stoneatom/stonedb/issues/733 revert code style
-
- 03 8月, 2022 1 次提交
-
-
由 hustjieke 提交于
[summary] 1. Change all engine stonedb to tianmu 2. Change SDB to tianmu 3. Also include mysql-test 4. Change file magic number to TianmuTB
-
- 07 7月, 2022 1 次提交
-
-
由 hustjieke 提交于
-
- 10 6月, 2022 1 次提交
-
-
由 hustjieke 提交于
-