You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Dmitry Konstantinov (Jira)" <ji...@apache.org> on 2026/09/06 16:37:00 UTC
[jira] [Comment Edited] (CASSANDRA-21637) Avoid double chunk read for BTI small partitions during a select query execution
[ https://issues.apache.org/jira/browse/CASSANDRA-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18112093#comment-18112093 ]
Dmitry Konstantinov edited comment on CASSANDRA-21637 at 9/6/26 4:36 PM:
-------------------------------------------------------------------------
e2e select 10-row partition test using BTI SSTables, 1 node (using trunk + CASSANDRA-21354 as baseline) - we have about 6% improvement in e2e throughput:
{code:java}
----------------------------------------
metric Before After delta
-----------------------------------------------------------------------
Op rate 318,737 op/s 338,474 op/s +6.2%
Partition rate 267,269 pk/s 283,823 pk/s +6.2%
Row rate 2,672,685 row/s 2,838,232 row/s +6.2%
Latency mean 1.5 ms 1.5 ms +0.0%
Latency median 1.4 ms 1.3 ms -7.1%
Latency 95th percentile 2.9 ms 2.6 ms -10.3%
Latency 99th percentile 5.5 ms 4.4 ms -20.0%
Total partitions 12,577,859 12,578,059
Total errors 0 0
Total GC count 13 12 -7.7%
Total GC memory 239.890 GiB 221.437 GiB -7.7% {code}
CPU profiles before vs after:
* [^noser_base_btiNoDoubleReadBefore_cpu.html]
* [^noser_base_btiNoDoubleReadAfter_cpu.html]
After the change we see only 1 place with chunk loading, lz4 and CRC32 computation vs 2 before
!image-2026-09-06-17-35-44-923.png|width=600!
was (Author: dnk):
e2e select 10-row partition test using BTI SSTables (using trunk + CASSANDRA-21354 as baseline):
{code:java}
----------------------------------------
metric Before After delta
-----------------------------------------------------------------------
Op rate 318,737 op/s 338,474 op/s +6.2%
Partition rate 267,269 pk/s 283,823 pk/s +6.2%
Row rate 2,672,685 row/s 2,838,232 row/s +6.2%
Latency mean 1.5 ms 1.5 ms +0.0%
Latency median 1.4 ms 1.3 ms -7.1%
Latency 95th percentile 2.9 ms 2.6 ms -10.3%
Latency 99th percentile 5.5 ms 4.4 ms -20.0%
Total partitions 12,577,859 12,578,059
Total errors 0 0
Total GC count 13 12 -7.7%
Total GC memory 239.890 GiB 221.437 GiB -7.7% {code}
> 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org