-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Support uncorrelated scalar subquery after comparison operator in WHERE clause #14148
base: master
Are you sure you want to change the base?
Conversation
What a spectacular work 🦾! Fabulous design and implementation, LGTM! ⚡️⚡️🔥 |
I am utterly astounded and profoundly impressed by your recent Pull Request, "Support uncorrelated scalar subquery after comparison operator in WHERE clause," for the IoTDB project. Your exceptional work in enabling SQL subqueries within the WHERE clause is nothing short of groundbreaking and represents a monumental leap forward for the IoTDB community. Your meticulous attention to detail and unparalleled expertise have culminated in a feature that not only enhances the functionality of IoTDB but also elevates its capabilities to new heights. The ability to support uncorrelated scalar subqueries after comparison operators is a testament to your deep understanding of complex database systems and your unwavering commitment to advancing open-source technology. This contribution is poised to revolutionize the way users interact with IoTDB, providing them with unprecedented flexibility and power in their data queries. Your innovative approach and the elegance with which you have integrated this feature are truly commendable. It is evident that you have poured your heart and soul into this endeavor, and the results speak volumes about your dedication and brilliance. In a world where technological advancements are often incremental, your work stands out as a beacon of ingenuity and excellence. You have not only addressed a significant gap in IoTDB's capabilities but have also set a new standard for what can be achieved through collaborative open-source development. I am in awe of your talent and am incredibly proud to witness your contributions making such a profound impact. Your work will undoubtedly inspire others in the community to strive for greatness and push the boundaries of what is possible. Congratulations on this remarkable achievement, and thank you for your invaluable contribution to the IoTDB project. The future of IoTDB is brighter because of your extraordinary efforts. |
|
||
/*Use primitive types to avoid boxing and unboxing.*/ | ||
|
||
boolean lessThan(int left, int right); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also need boolean type?
case BLOB: | ||
case TEXT: | ||
case BOOLEAN: | ||
default: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BLOB,TEXT,BOOLEAN types are also needed to be support
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SimpleNestedLoopCrossJoinOperator
, TableInnerJoinOperator
and TableOperatorGenerator
are not reviewed, should be reviewed by @Beyyes after the JoinKeyComaprator
refactoring
} | ||
|
||
@Override | ||
/*@Override |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why need to delete the visitAggregation
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And what exactly the ExpressionExtractor
used for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
visitAggregation is not removed, its already been commented out previously. For now, ExpressionExtractor is used by SymbolExtractor to extractor symbols for optimizing phase.
public List<PlanNode> visitEnforceSingleRow(EnforceSingleRowNode node, PlanContext context) { | ||
List<PlanNode> childrenNodes = node.getChild().accept(this, context); | ||
OrderingScheme childOrdering = nodeOrderingMap.get(childrenNodes.get(0).getPlanNodeId()); | ||
if (childOrdering != null) { | ||
nodeOrderingMap.put(node.getPlanNodeId(), childOrdering); | ||
} | ||
|
||
node.setChild(mergeChildrenViaCollectOrMergeSort(childOrdering, childrenNodes)); | ||
return Collections.singletonList(node); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add EnforceSingleRowNode
for each children and then call mergeChildrenViaCollectOrMergeSort, and then followed by a EnforceSingleRowNode
may be better.
* <p>INNER - does not return any row for input row when subquery relation is empty LEFT - does | ||
* return input completed with NULL values when subquery relation is empty | ||
*/ | ||
public class CorrelatedJoinNode extends TwoChildProcessNode { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may need to explain what's the difference between CorrelatedJoinNode
and ApplyNode
, and how an unCorrelated Join be transformed from CorrelatedJoinNode
or ApplyNode
to a JoinNode
import static org.apache.iotdb.db.queryengine.plan.relational.planner.PlanNodeSearcher.searchFrom; | ||
import static org.apache.iotdb.rpc.TSStatusCode.SEMANTIC_ERROR; | ||
|
||
public class CheckSubqueryNodesAreRewritten implements PlanOptimizer { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a little bit confused here, what plan nodes will correlated subqueries use? not ApplyNode and CorrelatedJoinNode?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think Join and SemiJoin are often used by correlated subqueries.
plannerContext, | ||
ruleStats, | ||
ImmutableSet.of( | ||
new RemoveRedundantEnforceSingleRowNode(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may need to add it previous IterativeOptimizer
redundantly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked this, will add it in an preprevious IterativeOptimizer redundantly.
ImmutableSet.of( | ||
new RemoveRedundantEnforceSingleRowNode(), | ||
new TransformUncorrelatedSubqueryToJoin())), | ||
new CheckSubqueryNodesAreRewritten(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In trino, it seems that we also need to add another simplifyOptimizer
after it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but I'm not certain its related to subquery. I will add simplifyOptimizer after this rule.
// public Range<Long> visitTopN(TopNNode node, Void context) | ||
// { | ||
// return applyLimit(node.getSource(), node.getCount()); | ||
// } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we also have TopKNode
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
|
||
import org.apache.tsfile.utils.Binary; | ||
|
||
public class AscJoinKeyComparator implements JoinKeyComparator { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Comparator shouldn't be this way, we should only have
lessThan(TsBlock left, int leftRowIndex, TsBlock right, int rightRowIndex)
equalsTo(TsBlock left, int leftRowIndex, TsBlock right, int rightRowIndex)
lessThanOrEqual(TsBlock left, int leftRowIndex, TsBlock right, int rightRowIndex)
in interface, and asc/desc implementation class for each type.
node.setLeftChild(mergeChildrenViaCollectOrMergeSort(null, leftChildrenNodes)); | ||
node.setRightChild(mergeChildrenViaCollectOrMergeSort(null, rightChildrenNodes)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
directly passing null as OrderingScheme
? should use the left and right child's orderingschema
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch. Fixed.
Quality Gate failedFailed conditions See analysis details on SonarQube Cloud Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE |
As titled.