-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
[improvement](nereids) Simplify ScanNode projection handling by removing redundant conditions #40801
Conversation
Thank you for your contribution to Apache Doris. Since 2024-03-18, the Document has been moved to doris-website. |
run buildall |
TPC-H: Total hot run time: 42806 ms
|
@@ -2008,20 +2008,10 @@ public PlanFragment visitPhysicalProject(PhysicalProject<? extends Plan> project | |||
// if we change the output order in translate project, the upper node will receive wrong order | |||
// tuple, since they get the order from project.getOutput() not scan.getOutput()./ | |||
List<SlotId> slotIdsByOrder = Lists.newArrayList(); |
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.
remove this variable
4803763
to
667d867
Compare
run buildall |
PR approved by at least one committer and no changes requested. |
PR approved by anyone and no changes requested. |
TPC-H: Total hot run time: 41251 ms
|
TPC-DS: Total hot run time: 190544 ms
|
ClickBench: Total hot run time: 33.43 s
|
…ing redundant conditions
run buildall |
TPC-H: Total hot run time: 40520 ms
|
TPC-DS: Total hot run time: 191477 ms
|
ClickBench: Total hot run time: 33.02 s
|
run cloud_p0 |
…ing redundant conditions (apache#40801) This PR simplifies the handling of `ScanNode` projection logic. Previously, the code included multiple conditional checks to determine whether a `projectionTuple` should be generated. These conditions have been removed, and now `projectionTuple `is always generated for `ScanNode`, ensuring a consistent projection setup. Additionally, redundant handling of `SlotId` and `SlotRef` has been eliminated, making the code cleaner and easier to maintain. The behavior for `OlapScanNode` remains unchanged.
…ing redundant conditions (#40801) (#41315) pick from master #40801 This PR simplifies the handling of `ScanNode` projection logic. Previously, the code included multiple conditional checks to determine whether a `projectionTuple` should be generated. These conditions have been removed, and now `projectionTuple `is always generated for `ScanNode`, ensuring a consistent projection setup. Additionally, redundant handling of `SlotId` and `SlotRef` has been eliminated, making the code cleaner and easier to maintain. The behavior for `OlapScanNode` remains unchanged.
…ing redundant conditions (#40801) This PR simplifies the handling of `ScanNode` projection logic. Previously, the code included multiple conditional checks to determine whether a `projectionTuple` should be generated. These conditions have been removed, and now `projectionTuple `is always generated for `ScanNode`, ensuring a consistent projection setup. Additionally, redundant handling of `SlotId` and `SlotRef` has been eliminated, making the code cleaner and easier to maintain. The behavior for `OlapScanNode` remains unchanged.
This PR simplifies the handling of
ScanNode
projection logic. Previously, the code included multiple conditional checks to determine whether aprojectionTuple
should be generated. These conditions have been removed, and nowprojectionTuple
is always generated forScanNode
, ensuring a consistent projection setup. Additionally, redundant handling ofSlotId
andSlotRef
has been eliminated, making the code cleaner and easier to maintain. The behavior forOlapScanNode
remains unchanged.