Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-8295

Investigate using the global visibility state stored on the reconciliation structure throughout rec_upd_select

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Reconciliation
    • Storage Engines
    • 20
    • StorEng - Refinement Pipeline

      This ticket came up as an idea from one of the issues encountered on WT-8074, the global visibility state is constantly changing and as a result of that the visibility of the selected update may change too. In one example we were choosing to save updates to the history store and then also clearing the time window of the chosen update. In another example specific logic exists in the code which re-checks global visibility to see if it has moved for a tombstone, see: https://github.com/wiredtiger/wiredtiger/blob/4116ce894259576f8a1a6cb1bbf99dc4e2a2b41b/src/reconcile/rec_visibility.c#L669

      We could reduce the complexity of the code by using the same saved view of global visibility throughout rather than re-checking, additionally this may result in the call to reconcile being somewhat faster.

      This ticket requires some discussion before scheduling as it would result in a number of changes in rec_visibility.c and possibly elsewhere, we could also extend it to using that saved state throughout the entirety of the reconcile call rather than just __wt_rec_upd_select.

      Currently a helper macro exists to check a start_tw against the saved reconciliation global state: https://github.com/wiredtiger/wiredtiger/blob/4116ce894259576f8a1a6cb1bbf99dc4e2a2b41b/src/include/reconcile_inline.h#L32

      Scope:

      • Understand the usages of global visibility checks in reconciliation
      • Design a solution to utilise the saved global visibility state or similar (alternate solution suggested in comments)
      • Implement the solution
      • Test the solution

            Assignee:
            backlog-server-storage-engines [DO NOT USE] Backlog - Storage Engines Team
            Reporter:
            luke.pearson@mongodb.com Luke Pearson
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: