[
https://issues.apache.org/jira/browse/CASSANDRA-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18112631#comment-18112631
]
Branimir Lambov commented on CASSANDRA-21637:
---------------------------------------------
Could you also verify the performance with chunk cache enabled? There must be a
difference with that as well and I'd much like to quantify it.
I never understood how not using the chunk cache can be the default, especially
with compression (the CASSANDRA-21134 tests also need a test with chunk cache
IMO).
> Avoid double chunk read for BTI small partitions during a select query
> execution
> --------------------------------------------------------------------------------
>
> Key: CASSANDRA-21637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21637
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
> Reporter: Dmitry Konstantinov
> Assignee: Dmitry Konstantinov
> Priority: Normal
> Fix For: 6.0.x, 7.x
>
> Attachments: image-2026-09-02-15-59-03-586.png,
> image-2026-09-06-17-35-44-923.png, noser_base_btiNoDoubleReadAfter_cpu.html,
> noser_base_btiNoDoubleReadBefore_cpu.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> BtiTableReader.getExactPosition() opens a data-file reader to verify the
> partition key when the trie payload is negative (means the partition small
> enough to have no row index entry). It then closed that reader, and
> AbstractSSTableIterator immediately reopened the same file at the same
> position. So, we read the same chunk twice in such scenario as well as run
> LZ4 decompression and CRC32 check twice. We can re-use the reader to avoid it.
> !image-2026-09-02-15-59-03-586.png|width=600!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
