-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Cache and Eviction, Reconciliation
-
Storage Engines
-
(copied to CRM)
-
8
-
2023-04-04 Bibbidi-Bobbidi-Boo, 2023-06-27 Lord of the Sprints, 2023-07-11 WiredTractor, 2023-07-25 Absolute unit, StorEng - 2023-08-08, ASeasonTooMany-2023-08-22, BermudaTriangle- 2023-09-05, TheMoon-StorEng - 2023-09-19, 2023-11-28 - Anthill Tiger, 2023-12-12 - Heisenbug, 2024-01-09 - I Grew Tired, StorEng - 2024-01-23, 2024-02-06 tapioooooooooooooca, 2024-02-20_A_near-death_puffin, 2024-03-05 - Claronald
-
v7.3, v7.0, v6.0, v5.0
Summary
The issue discussed in this ticket is related to WT-10424 (where the reproducer in the ticket description did not consider timestamps). After modifying the test with timestamps and implementing the WT-10424 solution, a regression was observed, particularly when the oldest timestamp was pinned. These symptoms are observed in multiple customer issues as well.
Acceptance criteria
- Provide an explanation for why
WT-10424is effective in non-timestamp cases but not in cases that involve timestamps. - Find the root cause of this performance regression
- Find solutions to fix the same
- causes
-
WT-12624 Investigate a ~4% improvement in "load time" and ~5% improvement in update throughput on 2024-02-27
- Open
- depends on
-
WT-11911 Fix use-after-free with bounded cursor and search_near
- Closed
-
WT-11667 Use scrub eviction to evict the page that with all deleted contents
- Closed
- related to
-
WT-10424 cursor::search_near slow performance if many deleted items are present
- Closed