You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
select span_name from records order by bit_length(attributes) desclimit20
And it's running out of memory with 20GB memory limit (RuntimeConfig::new().with_memory_limit(20 * 1024 * 1024 * 1024, 0.8)), and passing with 30GB allowed.
Error message is:
Failed to allocate additional 25887088 bytes for ExternalSorterMerge[1] with 585120448 bytes already allocated - maximum available is 23605759
The point is that in theory this query only needs to hold the span_names of the 20 records with the longest attributes in memory.
But even if it chose to hold all span_name in memory, it shouldn't need this much memory:
there's "only" 12_980_628 rows
with sum(bit_length(span_name)) = 1_038_805_400 aka ~1GB, for all rows
To Reproduce
The dataset and code aren't public, but It shouldn't be too hard to reproduce with a table containing 2 text columns
Expected behavior
Ideally a query like this would have a far more modest memory foot print.
Additional context
Using datafusion v38.0.0, same error with mimalloc and without.
For comparison, duckdb runs this query fine with a 1GB memory limit, but fails with 500MB.
After #13377 was merged, this is now much more memory-efficient and, in fact, works on just 1 GB for me 🎉 (Although I had to change bit_length to another function because we switched to string view when reading, but this type is not yet supported by bit_length)
Although I had to change bit_length to another function because we switched to string view when reading, but this type is not yet supported by bit_length
Is it possible this memory issue is related to bit_length only? Maybe we can support string view for bit_length then test it again
Activity
alamb commentedon May 16, 2024
@samuelcolvin can you share the query plan for this query? Specifically what is the output of this query?
I would also not expect it to consume 20GB of memory
samuelcolvin commentedon May 21, 2024
Sorry for the delay, here we go:
logical_planphysical_planalamb commentedon May 22, 2024
🤔 that certainly seems like it is doing a Top(K) with 14 cores -- so I would expect this would hold at most 20 * 14 batches
k🤔
blaginin commentedon Nov 9, 2024
Interestingly, the same data in CSV works fine, but Parquet causes a crash
blaginin commentedon Nov 9, 2024
take
blaginin commentedon Nov 16, 2024
After #13377 was merged, this is now much more memory-efficient and, in fact, works on just 1 GB for me 🎉 (Although I had to change
bit_lengthto another function because we switched to string view when reading, but this type is not yet supported bybit_length)I think we can close this issue
jayzhan211 commentedon Nov 17, 2024
Is it possible this memory issue is related to
bit_lengthonly? Maybe we can support string view forbit_lengththen test it againalamb commentedon Nov 19, 2024
I think this was recently merged
stringviewsupport toencodeanddecodeandbit_length#13332blaginin commentedon Nov 26, 2024
Just tested, everything works well with
bit_lengthtooalamb commentedon Nov 26, 2024
Nice!
So shall we close this ticket? Or is there still more work to do?
blaginin commentedon Nov 26, 2024
IMO we can close it if @samuelcolvin doesn't mind 🙂
samuelcolvin commentedon Nov 26, 2024
Closing, can always create a new issue if someone reproduces.
samuelcolvin commentedon Nov 26, 2024
Thank you so much for working on this.