-
-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug: If using semi join,maybe wrong result. #1559
Comments
The root cause maybe is not due to turn semijoin on. when it turns semijoin on, and run the query statement and it will lead to service coredump in debug mode. Therefore, if, the server runs in release mode, it's maybe not down, and returns wrong result.
in
The requirement of semi-join:
and if transform failed, then it will converted to derived table. [from MySQL]
Tiamnu generates join clause according to which type we support. From the code, we only support FULL, LEFT, RIGHT, INNER. |
The MTR is not sufficient for high quality, In closed PR: https://github.com/stoneatom/stonedb/pull/1322/files. More complex MTRs are requested, but it does not added in merged PR. such as [for example]: Complex query statement. |
and in
Taking the sql statement above as an example, it will take A and B as semijoin. but, it's inner join. From the analysis of above text, we know that stonedb try to convert to semijoin at sql layer, but tianmu engine does not support semijoin now very well. |
semijoin enable, miss
and its query plan is as following:
semi-join disabled: in this way, in statement is processed as subquery. As the codem,
and its query plan is listed below:
|
The code above has implicit bug, may lead to wrong error. the vector of data type is not same as (gdb) n
293 types::TianmuDataType &tianmu_dt(*r[col_id]);
(gdb)
294 switch (item->type()) {
(gdb) p tianmu_dt
$22 = (Tianmu::types::TianmuDataType &) <error reading variable>
(gdb) p col_id
$23 = 1
(gdb) p r
$24 = std::vector of length 1, capacity 1 = {std::unique_ptr<Tianmu::types::TianmuDataType> = {get() = 0x7f7e09c2dd70}}
(gdb) where This maybe introduced by And when executing the statement, the displable two attrs, the first is right one, but the second is wrong.
the second attrs:
The first one ins |
In fact, is in aggregation, we add an assertion here, and failed. It seems that
|
通过屏蔽主键和索引屏蔽掉semi join, 保证查询结果正确, 查询出错已解决,如果此后需要开发semi join,重新提交feature,此处处理与当前版本的处理保持一致 https://stoneatom.yuque.com/staff-ft8n1u/lsztbl/rxlhws22n0f1otxn/edit#AqyB |
Have you read the Contributing Guidelines on issues?
Please confirm if bug report does NOT exists already ?
Describe the problem
Expected behavior
No response
How To Reproduce
No response
Environment
./mysqld Ver 5.7.36-StoneDB-v1.0.3 for Linux on x86_64 (build-)
build information as follow:
Repository address: https://github.com/stoneatom/stonedb.git:stonedb-5.7-dev
Branch name: stonedb-5.7-dev
Last commit ID: 758bce8
Last commit time: Date: Mon Apr 10 19:46:20 2023 +0800
Build time: Date: Tue Apr 11 11:34:37 CST 2023
Are you interested in submitting a PR to solve the problem?
The text was updated successfully, but these errors were encountered: