Background

WT-17175 added approx_leaf_pages (exposed as the btree_row_leaf_pages stat) and leaf_entry_ewma (exposed as btree_row_leaf_avg_entries) to track an approximate row-store leaf page count and average entries per table. Both are maintained incrementally (splits for the former, page fault-in/reconciliation for the latter, in bt_split.c / btree_inline.h) and corrected exactly by a full tree walk in __stat_tree_walk (bt_stat.c) when a statistics=(tree_walk) cursor is opened.

For tables created after that change, both counters are accurate by construction (start at 0 on an empty tree, every subsequent split/access is tracked).

For tables created before that change, the checkpoint metadata simply has no approx_leaf_pages/leaf_entry_ewma entries. __ckpt_load (meta_ckpt.c) treats a missing key the same as a present-and-zero value, so both fields default to 0. This is indistinguishable from a genuinely empty table, and worse, a legacy table that receives a real write after upgrade gets a partially tracked, misleadingly nonzero count (only new splits are counted, pre-existing legacy pages are not).

This came up in a MongoDB query-planning discussion (#ask-wiredtiger Slack thread, 2026-07-07) - the consumer needs to know whether a 0 (or partially-tracked) reading can be trusted, so it can fall back to another estimation technique instead of trusting the value.

Approach

• WT_LEAF_STATS_UNKNOWN (UINT64_MAX) is used as a reserved marker value directly in approx_leaf_pages and leaf_entry_ewma - no new struct field, metadata key, or stat.
• A table whose checkpoint metadata predates this tracking loads both fields as the marker (__ckpt_load, meta_ckpt.c).
• Ordinary split (bt_split.c) and EWMA update (btree_inline.h) code leave both fields untouched while they hold the marker, so a legacy table never shows a partially-tracked, misleadingly nonzero value before an explicit correction.
• A WT_STAT_TYPE_TREE_WALK correction sets real values for both fields together, clearing the marker for good (the counters are then exact and incremental, so they can't drift back to unknown).

Definition of done

• A caller can distinguish "0/unknown because never corrected (a table that predates this tracking)" from "genuinely accurate" by checking for the WT_LEAF_STATS_UNKNOWN marker, without doing a tree walk itself.
• Existing incremental tracking behaviour for tables created after this change is unchanged.