[
https://issues.apache.org/jira/browse/CASSANDRA-21796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuqi Yan updated CASSANDRA-21796:
---------------------------------
Description:
Single-partition reads currently create an
{{UnfilteredRowIteratorWithLowerBound}} for every SSTable selected by the
interval tree before consulting its Bloom filter. With many overlapping
SSTables, this creates unnecessary lazy iterators and synthetic lower-bound
markers for SSTables that cannot contain the requested partition.
{{MergeIterator.ManyToOne}} wraps each input in a {{{}Candidate{}}}, whose
constructor calls {{{}lowerBound(){}}}. Non-null synthetic bounds are inserted
into the merge heap. When consumed, they are discarded without reaching the row
or range-tombstone reducer. The candidate then advances its underlying
iterator, triggering lazy initialization and eventually the Bloom-filter check
in {{{}getPosition(){}}}.
When the Bloom filter rejects the key, the source contributes no row, but the
iterator, lower-bound marker, candidate, merge structures, and associated heap
processing have already been allocated or performed.
Simply checking the Bloom filter before constructing the lower-bound iterator
prevents rejected SSTables from entering the merge-source list, reducing object
allocation and CPU overhead.
We don't want to add an extra check for positive case (sstable contains the
key) so some "exact one check" change for this path would be ideal.
(description polished with LLM)
was:
Single-partition reads currently create an
{{UnfilteredRowIteratorWithLowerBound}} for every SSTable selected by the
interval tree before consulting its Bloom filter. With many overlapping
SSTables, this creates unnecessary lazy iterators and synthetic lower-bound
markers for SSTables that cannot contain the requested partition.
{{MergeIterator.ManyToOne}} wraps each input in a {{{}Candidate{}}}, whose
constructor calls {{{}lowerBound(){}}}. Non-null synthetic bounds are inserted
into the merge heap. When consumed, they are discarded without reaching the row
or range-tombstone reducer. The candidate then advances its underlying
iterator, triggering lazy initialization and eventually the Bloom-filter check
in {{{}getPosition(){}}}.
When the Bloom filter rejects the key, the source contributes no row, but the
iterator, lower-bound marker, candidate, merge structures, and associated heap
processing have already been allocated or performed.
Simply checking the Bloom filter before constructing the lower-bound iterator
prevents rejected SSTables from entering the merge-source list, reducing object
allocation and CPU overhead.
We don't want to add an extra check for positive case (sstable contains the
key) so some "exact one check" for this path would be ideal.
(description polished with LLM)
> Reduce single-partition read allocations with an early Bloom filter check
> -------------------------------------------------------------------------
>
> Key: CASSANDRA-21796
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21796
> Project: Apache Cassandra
> Issue Type: Improvement
> Reporter: Yuqi Yan
> Assignee: Yuqi Yan
> Priority: Normal
>
> Single-partition reads currently create an
> {{UnfilteredRowIteratorWithLowerBound}} for every SSTable selected by the
> interval tree before consulting its Bloom filter. With many overlapping
> SSTables, this creates unnecessary lazy iterators and synthetic lower-bound
> markers for SSTables that cannot contain the requested partition.
> {{MergeIterator.ManyToOne}} wraps each input in a {{{}Candidate{}}}, whose
> constructor calls {{{}lowerBound(){}}}. Non-null synthetic bounds are
> inserted into the merge heap. When consumed, they are discarded without
> reaching the row or range-tombstone reducer. The candidate then advances its
> underlying iterator, triggering lazy initialization and eventually the
> Bloom-filter check in {{{}getPosition(){}}}.
> When the Bloom filter rejects the key, the source contributes no row, but the
> iterator, lower-bound marker, candidate, merge structures, and associated
> heap processing have already been allocated or performed.
> Simply checking the Bloom filter before constructing the lower-bound iterator
> prevents rejected SSTables from entering the merge-source list, reducing
> object allocation and CPU overhead.
>
> We don't want to add an extra check for positive case (sstable contains the
> key) so some "exact one check" change for this path would be ideal.
> (description polished with LLM)
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
