From the comment in WT-6002, it appears that there might be cases we are storing transaction IDs in the data store, when the workload doesn't even use timestamp:
For the update-only-btree workload, you can catch this in the test in __cell_pack_value_validity:
/* Globally visible values have no associated validity window. */ if (durable_start_ts == WT_TS_NONE && start_ts == WT_TS_NONE && start_txn == WT_TXN_NONE && durable_stop_ts == WT_TS_NONE && stop_ts == WT_TS_MAX && stop_txn == WT_TXN_MAX) { ++*pp; return; }
That test is true, except that start_txn != WT_TXN_NONE, and that triggers writing the transaction ID into the on-page cell, which adds about 5B to each cell where it happens, and so the page grows.
Since wtperf doesn't even use timestamps, there is no durable history as such, we should not be storing the transaction id in the data store.
- is depended on by
-
SERVER-47652 size of _id index 60% bigger
- Closed
-
WT-6151 Perform an empty check on time window before performing visibility check
- Closed
-
WT-5929 Perf degradation in update-only-btree test after durable history merge
- Closed
- is duplicated by
-
SERVER-47652 size of _id index 60% bigger
- Closed
-
WT-6132 Investigate reasons for bigger _id index after durable history drop
- Closed
- is related to
-
WT-6080 Add statistics to count frequency of saving validity window in the data store
- Closed
-
WT-6251 Fix splits to reduce the size of index files
- Closed
- related to
-
WT-6002 30% performance drop in updates when split_pct is set to 100
- Closed
-
WT-6114 Investigate performance drop in WT simple operations
- Closed
-
WT-6233 Add statistic to track the number of times we remove keys from the history store due to inserting 0 timestamped entries
- Closed
-
WT-6211 Review performance regression of global visibility checks in __inmem_row_leaf()
- Closed
-
WT-6220 Add statistics tracking when times are written to disk
- Closed