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
-
-
-
- Closed
-
-
WT-5929 Perf degradation in update-only-btree test after durable history merge
-
- Closed
-
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
- is related to
-
-
- Closed
-
-
-
- Closed
-
- related to
-
-
- Closed
-
-
WT-6114 Investigate performance drop in WT simple operations
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-