-
Notifications
You must be signed in to change notification settings - Fork 456
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
db: genericize rangeDel{Cache,Frags} into keySpan{Cache,Frags} #1356
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @jbowens)
mem_table.go, line 371 at r1 (raw file):
return nil } return frags.get(c.skl, c.cmp, c.formatKey)
Can't the code in this method extract these from m
like the callee used to do, and then call frags.get
. I am trying to understand why we need the member variables in keySpanCache
.
Or is this just the first step in the refactor and get
will eventually not take a memTable
parameter. Should it be removed now itself, since it is unused?
Rename the memtable's `rangeDelCache` and `rangeDelFrags` types to `keySpanCache` and `keySpanFrags` so they may be used for caching range key fragments too. In addition to the pure renames, I made a small refactor to decouple the dependency on `memTable.tombstones` by adding a pointer to the skiplist to a `keySpanCache` field.
There was a problem hiding this 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 1 files reviewed, 1 unresolved discussion (waiting on @sumeerbhola)
mem_table.go, line 371 at r1 (raw file):
Previously, sumeerbhola wrote…
Can't the code in this method extract these from
m
like the callee used to do, and then callfrags.get
. I am trying to understand why we need the member variables inkeySpanCache
.Or is this just the first step in the refactor and
get
will eventually not take amemTable
parameter. Should it be removed now itself, since it is unused?
Oops, yeah, I forgot to remove the memTable
parameter when extracting this change from another branch. Thanks :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @sumeerbhola)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TFTR!
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @sumeerbhola)
Rename the memtable's
rangeDelCache
andrangeDelFrags
types tokeySpanCache
andkeySpanFrags
so they may be used for caching rangekey fragments too.
In addition to the pure renames, I made a small refactor to decouple the
dependency on
memTable.tombstones
by adding a pointer to the skiplistin a
keySpanCache
field.