forked from cockroachdb/pebble
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
manifest: add methods for extending table bounds
Currently, `FileMetadata` exposes three pairs of keys representing bounds for a table - one each for point keys, range keys and the overall bounds for a table. The pair for the overall bounds for the table are a function of the point and range pairs and could technically be derived, but instead these overall bounds are materialized on the `FileMetadata` struct directly for performance reasons (it is faster to dereference the struct fields than making a function call to perform one or more comparisons). With the addition of two pairs of bounds in cockroachdb#1521 for the point and range bounds, there is a risk that a caller forgets to set a pair of bounds, violating the invariant that the overall point and range bounds are internally consistent with the point and range key bounds. To mitigate this risk, introduce methods on `manifest.FileMetadata` that can be used to "extend" the point or range key bounds for a table. These methods will maintain the invariant that the overall bounds for the table are computed directly from the point and range bounds. The methods, `MaybeExtend{Point,Range}KeyBounds`, are intended for "optimistic" use - a table's point, range and / or overall bounds may not necessarily be extended by a call to the respective methods if the existing bounds are smaller or larger than the provided bounds. This confines the comparisons to these method calls, as opposed to having the caller perform the checks to determine when bounds should be updated. As these fields are set once and read multiple times, this is considered a reasonable compromise. Update all existing call sites that directly set the existing `FileMetadata` smallest / largest bound fields to instead use the new methods for extending bounds. The only remaining call sites that set fields directly are limited to the `manifest` package and one call site in `ingest.go` that needs to mutate sequence numbers. These calls sites that store values in the fields directly are explicitly commented to indicate why the fields are being set directly. One alternative considered was to unexport the smallest / largest fields and gate access behind methods. However, as mentioned above, for performance reasons it beneficial to keep these fields exported.
- Loading branch information
Showing
22 changed files
with
1,153 additions
and
803 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.