-
Notifications
You must be signed in to change notification settings - Fork 256
[query] use lowered TableMapRows implementation
#14957
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
base: main
Are you sure you want to change the base?
Conversation
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.
It's annoying, but since this exposes two different previously unused code paths, I'd feel better if we knew they're exercised by tests. Could you try adding an assert(false) to each and making sure there are failing tests? (Assuming no tests fail without that.)
|
Sure. I'm confident these are not covered by tests. |
|
We're exercising the first branch where there are no extracted aggregations. Will remove that assertion and see if the second one is hit |
3de8c05 to
1b6a93c
Compare
|
Following the work concluded by #14762, benchmarks show no measurable differences in runtime between lowered and non-lowered implementation of
|
TableMapRows implementation
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.
Very excited to be deleting some old unlowered implementations!
| val extracted = agg.Extract(newRow, r.requirednessAnalysis, isScan = true) | ||
| TableValueIntermediate(recur(child).asTableValue(ctx).mapRows(extracted)) | ||
| case ir: TableMapRows => | ||
| TableStageIntermediate(ctx.backend.tableToTableStage(ctx, ir, r)) |
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.
This forces the entire child pipeline to be lowered, which isn't what we want here. See the TableJoin case as an example; we want to factor out the TableMapRows lowering implementation to be called directly from both the table lowering pass and here.
|
The test failures make me slightly nervous that the table benchmarks don't actually exercise the map rows for scans at all. |
Two of the cases in
TableValue.mapRowswere effectly redudant as they were implemented in single-branch if statements without an early return.None of these cases were tested and one was hidden behind a feature flag.
This change adopts the lowered execution path for TableMapRows after cloud benchmarks found no measurable performance differences between implementations.