Skip to content

Conversation

xxmplus
Copy link
Contributor

@xxmplus xxmplus commented Aug 29, 2025

Do not invalidate data block if bloomfilter returns false.

Fixes #4788

@xxmplus xxmplus requested a review from a team as a code owner August 29, 2025 23:15
@xxmplus xxmplus requested a review from sumeerbhola August 29, 2025 23:15
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Member

@RaduBerinde RaduBerinde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewable status: 0 of 3 files reviewed, 1 unresolved discussion (waiting on @sumeerbhola)


sstable/reader_iter_two_lvl.go line 447 at r1 (raw file):

		}
		if !mayContain {
			// In the no-error bloom filter miss case, the key definitely not in table.

[nit] is definitely not

Copy link
Collaborator

@jbowens jbowens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

@jbowens reviewed all commit messages.
Reviewable status: 0 of 3 files reviewed, 3 unresolved discussions (waiting on @sumeerbhola and @xxmplus)


-- commits line 2 at r1:
nit: s/feat:/sstable:/


sstable/reader_iter_two_lvl.go line 449 at r1 (raw file):

			// In the no-error bloom filter miss case, the key definitely not in table.
			// We can avoid invalidating the already loaded block since the caller is
			// not allowed to call Next when SeekPrefixGE returns nil.

I wonder if we could add an assertion for this in invariants builds. We'd need to remember the previous operation (or at least whether it was a SeekPrefixGE). We could store this information in an invariants.Value[T] type so that it compiles away on production builds, and then in Next() assert that the block is not invalidated in invariants.Enabled builds if the previous op was a SeekPrefixGE

@xxmplus xxmplus force-pushed the i4788-improve-block-invalidation branch from 33a7aea to 1a60cb6 Compare September 5, 2025 03:24
Copy link
Contributor Author

@xxmplus xxmplus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: 0 of 3 files reviewed, 3 unresolved discussions (waiting on @jbowens, @RaduBerinde, and @sumeerbhola)


-- commits line 2 at r1:

Previously, jbowens (Jackson Owens) wrote…

nit: s/feat:/sstable:/

updated.


sstable/reader_iter_two_lvl.go line 447 at r1 (raw file):

Previously, RaduBerinde wrote…

[nit] is definitely not

fixed.


sstable/reader_iter_two_lvl.go line 449 at r1 (raw file):

Previously, jbowens (Jackson Owens) wrote…

I wonder if we could add an assertion for this in invariants builds. We'd need to remember the previous operation (or at least whether it was a SeekPrefixGE). We could store this information in an invariants.Value[T] type so that it compiles away on production builds, and then in Next() assert that the block is not invalidated in invariants.Enabled builds if the previous op was a SeekPrefixGE

added.

@xxmplus xxmplus force-pushed the i4788-improve-block-invalidation branch from 4b5e0b3 to 01cc1c1 Compare September 5, 2025 03:58
@xxmplus xxmplus changed the title feat: do not invalidate data block if bloomfilter returns false sstable: do not invalidate data block if bloomfilter returns false Sep 5, 2025
@xxmplus xxmplus requested a review from jbowens September 5, 2025 04:22
@xxmplus
Copy link
Contributor Author

xxmplus commented Sep 5, 2025

@jbowens TFTR! I could use another review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

sstable: revisit possibly unnecessary block invalidations in iterator
4 participants