Implement ORDER BY spilling#14836
Conversation
b5ba144 to
fbb4976
Compare
|
Looks like the |
highker
left a comment
There was a problem hiding this comment.
LGTM % nits
- We need to fix the authoring as suggested by @tdcmeehan
presto-main/src/main/java/com/facebook/presto/SystemSessionProperties.java
Outdated
Show resolved
Hide resolved
presto-main/src/test/java/com/facebook/presto/operator/TestOrderByOperator.java
Outdated
Show resolved
Hide resolved
presto-main/src/test/java/com/facebook/presto/operator/TestOrderByOperator.java
Outdated
Show resolved
Hide resolved
155efc3 to
11e84ae
Compare
presto-main/src/test/java/com/facebook/presto/operator/TestOrderByOperator.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Should this be squashed with Add Spill To Disk for ORDER BY?
There was a problem hiding this comment.
I added this as a separate commit since it was a bug fixed in a later commit. However, that later commit also fixes the equivalent bug for window spilling. So, to make it explicit I just created a new commit. Can either squash this or leave it, no opinion on this.
wenleix
left a comment
There was a problem hiding this comment.
"Revoke memory after initial output page has been produced in tests".
The commit message says "Cherry-pick of trinodb/trino@5fef5aa". But looks very different to trinodb/trino@5fef5aa ? :)
There was a problem hiding this comment.
"Allow memory revoke only during operator finish phase" . Code LGTM. Just curious if you understand the motivation of this commit? @sachdevs -- so essentially we no longer revoke memory during operator execution phase, even some data is spilled to disk? -- Maybe the answer gets obvious when I look into the code :)
|
Good question Wenlei - the first 3 commits are pulled from a separate dependent PR for ORDER BY spilling. That commit makes much more sense in the context of that PR https://github.com/prestosql/presto/pull/164/files. Essentially there used to be a bug in Aggregation spilling that I also caught independently that is fixed in our trunk. The bug is as follows: HashAggregation memory revoking can be requested at any time - including after the operator has already run To further clarify, this is only for improving testing. I will be cherry picking their changes in to HashAggregation as well in a follow up PR. |
3fff9b1 to
d46f482
Compare
This was a typo - fixed in latest iteration |
Cherry-pick of trinodb/trino@0a9b804 Co-authored-by: Karol Sobczak <karol.sobczak@karolsobczak.com>
Cherry-pick of trinodb/trino@5fef5aa Co-authored-by: Karol Sobczak <karol.sobczak@karolsobczak.com>
Cherry-pick of trinodb/trino@e69b668 Co-authored-by: Karol Sobczak <karol.sobczak@karolsobczak.com>
Cherry-pick of trinodb/trino@f01067b Co-authored-by: Atri Sharma <atri@linux.com>
Cherry-pick of trinodb/trino@e7d8dd5 Co-authored-by: Piotr Findeisen <piotr.findeisen@gmail.com>
ORDER BY currently will error out if the data being processed exceeds query memory limit. This commit introduces paging from disk and ensures that ORDER BY is limited only by the amount of disk present. Cherry-pick of trinodb/trino@24868b3 Co-authored-by: Piotr Findeisen <piotr.findeisen@gmail.com>
Cherry-pick of trinodb/trino@472fb5a Co-authored-by: Karol Sobczak <karol.sobczak@karolsobczak.com>
Cherry-pick of trinodb/trino@d35e5fb Co-authored-by: Karol Sobczak <karol.sobczak@karolsobczak.com>
Cherry-pick of trinodb/trino@94b4d0a Co-authored-by: Karol Sobczak <karol.sobczak@karolsobczak.com>
d46f482 to
13db5e5
Compare
wenleix
left a comment
There was a problem hiding this comment.
LGTM. Make sure Travis turn green.
|
Test failure is unrelated (#14882). Other PRs also fail on the same test. |
PrestoSQL PR trinodb/trino#228
TODO