[
https://issues.apache.org/jira/browse/CASSANDRA-21354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated CASSANDRA-21354:
--------------------------------------------
Fix Version/s: 6.0-alpha3
7.0
(was: 7.x)
(was: 6.0.x)
Source Control Link:
https://github.com/apache/cassandra/commit/72affbc20669f1b610dd2c997fc1f6c642f017c5
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Avoid serialization and deserialization for coordinator-local single
> partition data read
> ----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-21354
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21354
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/Other
> Reporter: Dmitry Konstantinov
> Assignee: Dmitry Konstantinov
> Priority: Normal
> Fix For: 6.0-alpha3, 7.0
>
> Attachments: CASSANDRA-21354-trunk-ci_summary_Sep16.html,
> image-2026-05-07-10-10-16-886.png, may3_max_alloc.html,
> may6_noser_alloc.html, read_noser_proto_trunk_ci_summary.htm
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently when we execute a local read we fetch data from SSTables and
> Memtables using a merging iterator and write it to a byte buffer. Later when
> we combine a CQL response we deserialize the data back to iterate over them
> as a part of coordinator logic. So, we allocate rows and cells twice here,
> during the read from SSTables/Memtables and during the deserialization by
> coordinator logic if we read data locally (it is a typical scenario because
> usually drivers are sending requests to replicas).
> The idea of optimization: if we do a single partition read of a small number
> of rows we can keep the data in memory and avoid this double row objects
> allocation.
> We should limit amount of such data kept in memory to avoid too much pressure
> on GC due to extended lifetime for these objects and promoting them to an old
> generation.
> So, a system property can be used to limit number of rows we keep in memory
> in this scenario, as well as to disable the logic in case of any issues.
> We cannot get a number of rows in advance, so we do a rows limiting logic in
> the following way: we read first N rows to memory and if we still have
> something we serialize the remaining to a buffer and then concatenate
> iterators for the in-memory rows + deserialized one
> !image-2026-05-07-10-10-16-886.png|width=800!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
