Repository navigation
Support merge-before-filter compaction (#15517) - #15517
Open
xingbowang wants to merge 1 commit into
Open
xingbowang wants to merge 1 commit into
xingbowang wants to merge 1 commit into
Conversation
|
@xingbowang has exported this pull request. If you are a Meta employee, you can view the originating Diff in D128313536. |
|
| Check | Count |
|---|---|
clang-analyzer-optin.core.EnumCastOutOfRange |
4 |
clang-analyzer-optin.performance.Padding |
1 |
cppcoreguidelines-special-member-functions |
1 |
modernize-use-emplace |
4 |
performance-inefficient-vector-operation |
1 |
| Total | 11 |
Details
db/compaction/compaction_iterator_test.cc (4 warning(s))
db/compaction/compaction_iterator_test.cc:640:16: warning: use emplace_back instead of push_back [modernize-use-emplace]
db/compaction/compaction_iterator_test.cc:643:14: warning: use emplace_back instead of push_back [modernize-use-emplace]
db/compaction/compaction_iterator_test.cc:687:18: warning: use emplace_back instead of push_back [modernize-use-emplace]
db/compaction/compaction_iterator_test.cc:704:20: warning: use emplace_back instead of push_back [modernize-use-emplace]
db/db_compaction_filter_test.cc (3 warning(s))
db/db_compaction_filter_test.cc:36:7: warning: 'push_back' is called inside a loop; consider pre-allocating the container capacity before the loop [performance-inefficient-vector-operation]
db/db_compaction_filter_test.cc:1070:38: warning: The value '99' provided to the cast expression is not in the valid range of values for 'MergeOrder' [clang-analyzer-optin.core.EnumCastOutOfRange]
db/db_compaction_filter_test.cc:1075:53: warning: The value '99' provided to the cast expression is not in the valid range of values for 'MergeOrder' [clang-analyzer-optin.core.EnumCastOutOfRange]
db/flush_job_test.cc (1 warning(s))
db/flush_job_test.cc:190:9: warning: class 'Filter' defines a non-default destructor but does not define a copy constructor, a copy assignment operator, a move constructor or a move assignment operator [cppcoreguidelines-special-member-functions]
utilities/blob_db/blob_db_test.cc (3 warning(s))
utilities/blob_db/blob_db_test.cc:1003:25: warning: The value '255' provided to the cast expression is not in the valid range of values for 'MergeOrder' [clang-analyzer-optin.core.EnumCastOutOfRange]
utilities/blob_db/blob_db_test.cc:1004:10: warning: Excessive padding in 'struct Case' (8 padding bytes, where 0 is optimal). Optimal fields order: direct_order, factory_order, direct, factory, invalid_argument, not_supported, consider reordering the fields or adding explicit padding members [clang-analyzer-optin.performance.Padding]
utilities/blob_db/blob_db_test.cc:1093:11: warning: The value '255' provided to the cast expression is not in the valid range of values for 'MergeOrder' [clang-analyzer-optin.core.EnumCastOutOfRange]
xingbowang
force-pushed
the
export-D128313536
branch
from
October 30, 2026 00:09
38171fe to
2ddc584
Compare
xingbowang
added a commit
to xingbowang/rocksdb
that referenced
this pull request
Oct 30, 2026
Summary: Pull Request resolved: meta#15517 ## Why Applications need to filter the logical merge result. Previously, compaction filters ran before merging and could remove individual operands before the merge operator evaluated them. ## Behavior The default remains filter-before-merge. Filters and factories can opt into merge-before-filter through `GetMergeOrder()`. The existing `FilterV4` receives full values/entities, partial merge operands, or individual untouched operands when partial merge declines. Successful aggregates are offered once; changed operands are not merged again in the same pass. Snapshot eligibility covers every retained operand. Stored values retain normal filtering rules, including sequence zero; aggregates containing ineligible operands are not filtered. New-order value/entity `kPurge` uses ordinary Delete semantics for input records, merge results, and later compactions. Unsupported operand decisions return errors. ## Implementation `MergeHelper` stages outcomes and eligibility; `CompactionIterator` handles filtering, removal and range skips, including the advanced cursor after a full merge. Production factory/order checks run outside the DB mutex. Open and CF creation reject new-order factories selecting non-compaction creation; flush/recovery/mempurge retain runtime guards. Repair explicitly checks the table builder's `IOStatus` while preserving earlier error precedence. Purge normalization has a ticker. Compatible services advertise support, transport core request format 2, and acknowledge the worker's actual filter order. Missing capability, service `kUseLocal`, and validated compatibility declines fall back locally before output import. Old core workers reject format 2 with `NotSupported`; integrator decline policy determines whether that becomes local fallback. Real errors remain errors. Service integration is supplied separately and activated by the normal RocksDB release. ## Safety and limitations `FilterV4` and value types remain unchanged; there is no persisted SST-format change, new CF option, or C/Java binding. New virtual methods and job metadata require rebuilding applications, filters, factories, services and workers against matching headers/libraries. Binary rollback requires a compatible rebuild. Normalized purge cannot be mixed with SingleDelete for the same keys. Integrated BlobDB is supported. SnapshotChecker, timestamps and stacked BlobDB are unsupported; SnapshotChecker and timestamps remain follow-ups. Merge grouping can change callback inputs and policy outcomes; existing callback lifetime/exception rules apply. Focused native tests cover merge/filter and remote routing behavior. Full-suite, current sanitizer and benchmark validation are unavailable. Five established immutable-baseline checked-status failures remain unresolved and unwaived. No performance or production rollout claim is made. Differential Revision: D128313536
xingbowang
force-pushed
the
export-D128313536
branch
from
October 30, 2026 11:22
2ddc584 to
83cbe3e
Compare
xingbowang
added a commit
to xingbowang/rocksdb
that referenced
this pull request
Oct 30, 2026
Summary: Pull Request resolved: meta#15517 ## Why Applications need to filter the logical merge result. Previously, compaction filters ran before merging and could remove individual operands before the merge operator evaluated them. ## Behavior The default remains filter-before-merge. Filters and factories can opt into merge-before-filter through `GetMergeOrder()`. The existing `FilterV4` receives full values/entities, partial merge operands, or individual untouched operands when partial merge declines. Successful aggregates are offered once; changed operands are not merged again in the same pass. Snapshot eligibility covers every retained operand. Stored values retain normal filtering rules, including sequence zero; aggregates containing ineligible operands are not filtered. New-order value/entity `kPurge` uses ordinary Delete semantics for input records, merge results, and later compactions. Unsupported operand decisions return errors. ### Example Counter merge operator (add) with a filter that removes counters below 10. The compaction input for one key is `Merge(+3)`, `Merge(+5)`, `Put(4)`. Before: the filter sees the raw operands `+3` and `+5`, removes both, and the output is `Put(4)`; it never sees the merged value. After: the merge runs first (4 + 5 + 3 = 12) and `FilterV4` sees `kValue` "12" and keeps it. If the base is not in the compaction, partial merge gives `+8` and `FilterV4` sees it as `kMergeOperand`. ## Implementation `MergeHelper` stages outcomes and eligibility; `CompactionIterator` handles filtering, removal and range skips, including the advanced cursor after a full merge. Production factory/order checks run outside the DB mutex. Open and CF creation reject new-order factories selecting non-compaction creation; flush/recovery/mempurge retain runtime guards. Repair explicitly checks the table builder's `IOStatus` while preserving earlier error precedence. Purge normalization has a ticker. Compatible services advertise support and the worker acknowledges its actual filter order. Missing capability, service `kUseLocal`, and results without a matching acknowledgment fall back locally before output import; old workers ignore the new request field and return no acknowledgment, so they fall back too. Real errors remain errors. Service integration is supplied separately and activated by the normal RocksDB release. ## Safety and limitations `FilterV4` and value types remain unchanged; there is no persisted SST-format change, new CF option, or C/Java binding. New virtual methods and job metadata require rebuilding applications, filters, factories, services and workers against matching headers/libraries. Binary rollback requires a compatible rebuild. Normalized purge cannot be mixed with SingleDelete for the same keys. Integrated BlobDB is supported. SnapshotChecker, timestamps and stacked BlobDB are unsupported; SnapshotChecker and timestamps remain follow-ups. Merge grouping can change callback inputs and policy outcomes; existing callback lifetime/exception rules apply. Focused native tests cover merge/filter and remote routing behavior. Full-suite, current sanitizer and benchmark validation are unavailable. Five established immutable-baseline checked-status failures remain unresolved and unwaived. No performance or production rollout claim is made. Differential Revision: D128313536
xingbowang
force-pushed
the
export-D128313536
branch
from
October 30, 2026 12:53
83cbe3e to
bcf6863
Compare
xingbowang
added a commit
to xingbowang/rocksdb
that referenced
this pull request
Oct 30, 2026
Summary: Pull Request resolved: meta#15517 ## Why Applications need to filter the logical merge result. Previously, compaction filters ran before merging and could remove individual operands before the merge operator evaluated them. ## Behavior The default remains filter-before-merge. Filters and factories can opt into merge-before-filter through `GetMergeOrder()`. The existing `FilterV4` receives full values/entities, partial merge operands, or individual untouched operands when partial merge declines. Successful aggregates are offered once; changed operands are not merged again in the same pass. Snapshot eligibility covers every retained operand. Stored values retain normal filtering rules, including sequence zero; aggregates containing ineligible operands are not filtered. New-order value/entity `kPurge` uses ordinary Delete semantics for input records, merge results, and later compactions. Unsupported operand decisions return errors. ### Example Counter merge operator (add) with a filter that removes counters below 10. The compaction input for one key is `Merge(+3)`, `Merge(+5)`, `Put(4)`. Before: the filter sees the raw operands `+3` and `+5`, removes both, and the output is `Put(4)`; it never sees the merged value. After: the merge runs first (4 + 5 + 3 = 12) and `FilterV4` sees `kValue` "12" and keeps it. If the base is not in the compaction, partial merge gives `+8` and `FilterV4` sees it as `kMergeOperand`. ## Implementation `MergeHelper` stages outcomes and eligibility; `CompactionIterator` handles filtering, removal and range skips, including the advanced cursor after a full merge. Production factory/order checks run outside the DB mutex. Open and CF creation reject new-order factories selecting non-compaction creation; flush/recovery/mempurge retain runtime guards. Repair explicitly checks the table builder's `IOStatus` while preserving earlier error precedence. Purge normalization has a ticker. Compatible services advertise support and the worker acknowledges its actual filter order. Missing capability, service `kUseLocal`, and results without a matching acknowledgment fall back locally before output import; old workers ignore the new request field and return no acknowledgment, so they fall back too. Real errors remain errors. Service integration is supplied separately and activated by the normal RocksDB release. ## Safety and limitations `FilterV4` and value types remain unchanged; there is no persisted SST-format change, new CF option, or C/Java binding. New virtual methods and job metadata require rebuilding applications, filters, factories, services and workers against matching headers/libraries. Binary rollback requires a compatible rebuild. Normalized purge cannot be mixed with SingleDelete for the same keys. Integrated BlobDB is supported. SnapshotChecker, timestamps and stacked BlobDB are unsupported; SnapshotChecker and timestamps remain follow-ups. Merge grouping can change callback inputs and policy outcomes; existing callback lifetime/exception rules apply. Focused native tests cover merge/filter and remote routing behavior. Full-suite, current sanitizer and benchmark validation are unavailable. Five established immutable-baseline checked-status failures remain unresolved and unwaived. No performance or production rollout claim is made. Differential Revision: D128313536
xingbowang
force-pushed
the
export-D128313536
branch
from
October 30, 2026 12:57
bcf6863 to
3de49f0
Compare
xingbowang
added a commit
to xingbowang/rocksdb
that referenced
this pull request
Oct 30, 2026
Summary: Pull Request resolved: meta#15517 ## Why Applications need to filter the logical merge result. Previously, compaction filters ran before merging and could remove individual operands before the merge operator evaluated them. ## Behavior The default remains filter-before-merge. Filters and factories can opt into merge-before-filter through `GetMergeOrder()`. The existing `FilterV4` receives full values/entities, partial merge operands, or individual untouched operands when partial merge declines. Successful aggregates are offered once; changed operands are not merged again in the same pass. Snapshot eligibility covers every retained operand. Stored values retain normal filtering rules, including sequence zero; aggregates containing ineligible operands are not filtered. New-order value/entity `kPurge` uses ordinary Delete semantics for input records, merge results, and later compactions. Unsupported operand decisions return errors. ### Example Counter merge operator (add) with a filter that removes counters below 10. The compaction input for one key is `Merge(+3)`, `Merge(+5)`, `Put(4)`. Before: the filter sees the raw operands `+3` and `+5`, removes both, and the output is `Put(4)`; it never sees the merged value. After: the merge runs first (4 + 5 + 3 = 12) and `FilterV4` sees `kValue` "12" and keeps it. If the base is not in the compaction, partial merge gives `+8` and `FilterV4` sees it as `kMergeOperand`. ## Implementation `MergeHelper` stages outcomes and eligibility; `CompactionIterator` handles filtering, removal and range skips, including the advanced cursor after a full merge. Production factory/order checks run outside the DB mutex. Open and CF creation reject new-order factories selecting non-compaction creation; flush/recovery/mempurge retain runtime guards. Repair explicitly checks the table builder's `IOStatus` while preserving earlier error precedence. Purge normalization has a ticker. Compatible services advertise support and the worker acknowledges its actual filter order. Missing capability, service `kUseLocal`, and results without a matching acknowledgment fall back locally before output import; old workers ignore the new request field and return no acknowledgment, so they fall back too. Real errors remain errors. Service integration is supplied separately and activated by the normal RocksDB release. ## Safety and limitations `FilterV4` and value types remain unchanged; there is no persisted SST-format change, new CF option, or C/Java binding. New virtual methods and job metadata require rebuilding applications, filters, factories, services and workers against matching headers/libraries. Binary rollback requires a compatible rebuild. Normalized purge cannot be mixed with SingleDelete for the same keys. Integrated BlobDB is supported. SnapshotChecker, timestamps and stacked BlobDB are unsupported; SnapshotChecker and timestamps remain follow-ups. Merge grouping can change callback inputs and policy outcomes; existing callback lifetime/exception rules apply. Focused native tests cover merge/filter and remote routing behavior. Full-suite, current sanitizer and benchmark validation are unavailable. Five established immutable-baseline checked-status failures remain unresolved and unwaived. No performance or production rollout claim is made. Differential Revision: D128313536
xingbowang
force-pushed
the
export-D128313536
branch
from
October 30, 2026 13:51
3de49f0 to
d22d3f7
Compare
Summary: Pull Request resolved: meta#15517 ## Why Applications need to filter the logical merge result. Previously, compaction filters ran before merging and could remove individual operands before the merge operator evaluated them. ## Behavior The default remains filter-before-merge. Filters and factories can opt into merge-before-filter through `GetMergeOrder()`. The existing `FilterV4` receives full values/entities, partial merge operands, or individual untouched operands when partial merge declines. Successful aggregates are offered once; changed operands are not merged again in the same pass. Snapshot eligibility covers every retained operand. Stored values retain normal filtering rules, including sequence zero; aggregates containing ineligible operands are not filtered. New-order value/entity `kPurge` uses ordinary Delete semantics for input records, merge results, and later compactions. Unsupported operand decisions return errors. ### Example Counter merge operator (add) with a filter that removes counters below 10. The compaction input for one key is `Merge(+3)`, `Merge(+5)`, `Put(4)`. Before: the filter sees the raw operands `+3` and `+5`, removes both, and the output is `Put(4)`; it never sees the merged value. After: the merge runs first (4 + 5 + 3 = 12) and `FilterV4` sees `kValue` "12" and keeps it. If the base is not in the compaction, partial merge gives `+8` and `FilterV4` sees it as `kMergeOperand`. ## Implementation `MergeHelper` stages outcomes and eligibility; `CompactionIterator` handles filtering, removal and range skips, including the advanced cursor after a full merge. Production factory/order checks run outside the DB mutex. Open and CF creation reject new-order factories selecting non-compaction creation; flush/recovery/mempurge retain runtime guards. Repair explicitly checks the table builder's `IOStatus` while preserving earlier error precedence. Purge normalization has a ticker. Compatible services advertise support and the worker acknowledges its actual filter order. Missing capability, service `kUseLocal`, and results without a matching acknowledgment fall back locally before output import; old workers ignore the new request field and return no acknowledgment, so they fall back too. Real errors remain errors. Service integration is supplied separately and activated by the normal RocksDB release. ## Safety and limitations `FilterV4` and value types remain unchanged; there is no persisted SST-format change, new CF option, or C/Java binding. New virtual methods and job metadata require rebuilding applications, filters, factories, services and workers against matching headers/libraries. Binary rollback requires a compatible rebuild. Normalized purge cannot be mixed with SingleDelete for the same keys. Integrated BlobDB is supported. SnapshotChecker, timestamps and stacked BlobDB are unsupported; SnapshotChecker and timestamps remain follow-ups. Merge grouping can change callback inputs and policy outcomes; existing callback lifetime/exception rules apply. Focused native tests cover merge/filter and remote routing behavior. Full-suite, current sanitizer and benchmark validation are unavailable. Five established immutable-baseline checked-status failures remain unresolved and unwaived. No performance or production rollout claim is made. Differential Revision: D128313536
xingbowang
force-pushed
the
export-D128313536
branch
from
October 30, 2026 13:55
d22d3f7 to
484feb5
Compare
This branch has not been deployed
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
Why
Applications need to filter the logical merge result. Previously, compaction filters ran before merging and could remove individual operands before the merge operator evaluated them.
Behavior
The default remains filter-before-merge. Filters and factories can opt into merge-before-filter through
GetMergeOrder(). The existingFilterV4receives full values/entities, partial merge operands, or individual untouched operands when partial merge declines. Successful aggregates are offered once; changed operands are not merged again in the same pass.Snapshot eligibility covers every retained operand. Stored values retain normal filtering rules, including sequence zero; aggregates containing ineligible operands are not filtered. New-order value/entity
kPurgeuses ordinary Delete semantics for input records, merge results, and later compactions. Unsupported operand decisions return errors.Example
Counter merge operator (add) with a filter that removes counters below 10. The compaction input for one key is
Merge(+3),Merge(+5),Put(4). Before: the filter sees the raw operands+3and+5, removes both, and the output isPut(4); it never sees the merged value. After: the merge runs first (4 + 5 + 3 = 12) andFilterV4seeskValue"12" and keeps it. If the base is not in the compaction, partial merge gives+8andFilterV4sees it askMergeOperand.Implementation
MergeHelperstages outcomes and eligibility;CompactionIteratorhandles filtering, removal and range skips, including the advanced cursor after a full merge. Production factory/order checks run outside the DB mutex. Open and CF creation reject new-order factories selecting non-compaction creation; flush/recovery/mempurge retain runtime guards. Repair explicitly checks the table builder'sIOStatuswhile preserving earlier error precedence. Purge normalization has a ticker.Compatible services advertise support and the worker acknowledges its actual filter order. Missing capability, service
kUseLocal, and results without a matching acknowledgment fall back locally before output import; old workers ignore the new request field and return no acknowledgment, so they fall back too. Real errors remain errors. Service integration is supplied separately and activated by the normal RocksDB release.Safety and limitations
FilterV4and value types remain unchanged; there is no persisted SST-format change, new CF option, or C/Java binding. New virtual methods and job metadata require rebuilding applications, filters, factories, services and workers against matching headers/libraries. Binary rollback requires a compatible rebuild. Normalized purge cannot be mixed with SingleDelete for the same keys.Integrated BlobDB is supported. SnapshotChecker, timestamps and stacked BlobDB are unsupported; SnapshotChecker and timestamps remain follow-ups. Merge grouping can change callback inputs and policy outcomes; existing callback lifetime/exception rules apply.
Focused native tests cover merge/filter and remote routing behavior. Full-suite, current sanitizer and benchmark validation are unavailable. Five established immutable-baseline checked-status failures remain unresolved and unwaived. No performance or production rollout claim is made.
Differential Revision: D128313536