- 01 11月, 2022 2 次提交
- 31 10月, 2022 1 次提交
-
-
由 shizhao 提交于
-
- 28 10月, 2022 1 次提交
-
-
由 shizhao 提交于
-
- 27 10月, 2022 3 次提交
-
-
由 shangyanwen 提交于
-
由 shangyanwen 提交于
-
由 shangyanwen 提交于
-
- 26 10月, 2022 8 次提交
-
-
由 shangyanwen 提交于
-
由 shangyanwen 提交于
-
由 shangyanwen 提交于
-
由 shangyanwen 提交于
-
由 shangyanwen 提交于
-
由 shangyanwen 提交于
-
由 shangyanwen 提交于
-
由 shizhao 提交于
-
- 25 10月, 2022 3 次提交
-
-
由 shizhao 提交于
-
由 shizhao 提交于
-
由 lihongjian 提交于
Cause: When the date in MySQL is 0, the value is considered to be null. MySQL handles this problem. If you query the statement of isull, you will convert isnull to=0. This problem is that the value with the date of 0 is inserted into the table. The query and deletion results of the tianmu engine are not consistent. The reason for the inconsistency is that the syntax parsing logic of the query and deletion of tianmu is not the same Solution: Unified query logic and modification logic for date format processing. Keep the phenomenon of tianmu consistent with innodb.
-
- 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 5 次提交
-
-
由 悟世者 提交于
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)));
-
由 lujiashun 提交于
[summary] 1 the root reason is because of the variable ‘tianmu_insert_delayed’,set it off; 2 in debug version, it crashes, fix it; 3 add mtr case for this issue;
-
由 lylth 提交于
Replace the function FindCurrentRowByVMTable that gets the current row to FindCurrentRow.
-
由 shizhao 提交于
-
- 20 10月, 2022 1 次提交
-
-
由 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 1 次提交
-
-
由 悟世者 提交于
fix issuse 468 461 mtr result
-
- 17 10月, 2022 1 次提交
-
-
由 lihongjian 提交于
Cause: Execution plan error when AND/OR sql logical operator in condition occurs at the same time Resolvent: Optimize multiple equal execution plan logic
-
- 13 10月, 2022 6 次提交
-
-
由 fuxiang 提交于
-
由 lihongjian 提交于
Cause of the problem: The tianmu engine created join objects in syntax optimization, but did not explain them Modify Scheme: Release the join object after use
-
由 fuxiang 提交于
-
由 fuxiang 提交于
-
由 lihongjian 提交于
Cause of the problem: In the mode where the type is ref, the line number returned by the tianmu engine is 10 by default. Modify Scheme: Delete the logic that returns 10 rows by default, and return the number of rows in the table instead.
-
由 lujiashun 提交于
[summary] 1 change tianmu status var scope from SHOW_SCOPE_UNDEF to SHOW_SCOPE_GLOBAL;
-
- 12 10月, 2022 7 次提交
-
-
由 悟世者 提交于
-
由 悟世者 提交于
-
由 悟世者 提交于
-
由 悟世者 提交于
-
由 悟世者 提交于
remote CREATE TABLE t1 (a int not null,b int not null)ENGINE=TIANMU; CREATE TABLE t2 (a int not null, b int not null, primary key (a,b))ENGINE=TIANMU; CREATE TABLE t3 (a int not null, b int not null, primary key (a,b))ENGINE=TIANMU; insert into t1 values (1,1),(2,1),(1,3); insert into t2 values (1,1),(2,2),(3,3); insert into t3 values (1,1),(2,1),(1,3); select * from t1,t2,t3 where t1.a=t2.a AND t2.b=t3.a and t1.b=t3.b; delete t2.*,t3.* from t1,t2,t3 where t1.a=t2.a AND t2.b=t3.a and t1.b=t3.b; # This should be empty select * from t3; drop table t1,t2,t3; delete t2.*,t3.* from t1,t2,t3 where t1.a=t2.a AND t2.b=t3.a and t1.b=t3.b; select * from t3; ab delete t2.*,t3.* from t1,t2,t3 where t1.a=t2.a AND t2.b=t3.a and t1.b=t3.b; select * from t3; ab 11 21 13 because of https://github.com/stoneatom/stonedb/issues/678
-
由 悟世者 提交于
-- error ER_UPDATE_WITHOUT_KEY_IN_SAFE_MODE DELETE t2 FROM t1 JOIN t2 WHERE t1.a = 10;
-
由 悟世者 提交于
remove explain, Currently, the query plan is in the process of change and modification, and the consistency check of the query plan is not performed
-