-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: 8.1.0-rc0
-
Component/s: None
-
Catalog and Routing
-
ALL
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Some query optimizations take advantage of the bucket granularity being fixed since the collection creation. This is tracked through a timeseriesBucketingParametersHaveChanged flag, which is set to false on collection creation and changed to true if the granularity is changed by collMod.
In SERVER-91193 it was discovered that the because the original flag was outside of the collection options, it could be lost in some scenarios. Since SERVER-91195 we can safely persist the flag in md.options.storageEngine.wiredTiger. The problem however is that setting this flag to false on creation is problematic because:
- It changes the user-visible listCollections output, and
- When the idempotency checks on createCollection compare the storageEngine object, they should ignore the flag
This ticket is for finding a solution to this problem - note the fixed bucketing optimization feature is currently disabled because of this.
It may be closed if SERVER-92265 is done first.
- depends on
-
SERVER-92265 Provide a reliable way to persist additional catalog options rather than using the configString workaround
-
- Backlog
-
- is depended on by
-
SERVER-96993 Reenable time-series fixed bucket optimizations
-
- Blocked
-
- is related to
-
SERVER-91193 timeseriesBucketingParametersHaveChanged not properly cloned upon data migration/initial sync/restore
-
- Closed
-
-
SERVER-91195 Provide a generic backportable solution not to miss top-level timeseries collection options
-
- Closed
-
- related to
-
SERVER-91231 Get rid of md.timeseriesBucketingParametersHaveChanged for avoiding confusion/misuses
-
- Closed
-