Background

WT-18406 (PR 14561) skips reading a WT_REF_DISK internal page when the address-cell time aggregate shows the whole subtree is deleted and visible. The skip is enabled only on disaggregated trees (WT_BTREE_DISAGGREGATED).

On the local block manager (ASC), __wt_btcur_skip_page() still returns immediately for every internal ref:

Trees on the local block manager never skip an internal page. Reading one in is what marks it dirty for the deleted children it references, and the reconciliation that follows is what frees their blocks. The checkpoint cleanup thread is otherwise the only trigger and runs too rarely to bound the space a truncate-heavy workload holds.

Chenhao accepted that this PR stay disagg-only, and asked for a ticket to evaluate whether the local block manager can skip as well.

This ticket is the evaluation, not an implementation commitment.

Why ASC cannot skip today

Skipping an emptied internal avoids the read, so the parent never sees the deleted children as in-memory, never marks itself dirty, and never reconciles. On disagg, page lifetime is owned by PALI / the page service, so that is acceptable. On ASC, reconciliation of the parent is what returns the child extents to the local block manager. Skip the read and those blocks stay allocated until some other path (checkpoint cleanup) happens to walk the same internals.

Checkpoint cleanup (_checkpoint_cleanup_page_skip / _checkpoint_cleanup_obsolete_cleanup) is that other path, and it must read internals to do the work. It is also infrequent relative to a truncate-heavy cursor walk, which is why WT-18406 left ASC internals unskipped.

Logged / non-timestamp tables (oplog) get little from the skip anyway: there is no snapshot stop point that makes a whole subtree invisible.

What to evaluate

• Can ASC free the child extents of a skipped emptied internal without reading that page? For example by recording extents in the address cell, a side structure, or a later dedicated reclamation walk that is frequent enough.
• If not, is there a narrower case (timestamped tables only, or after checkpoint cleanup has already rewritten the parent) where skipping is safe because the blocks are already free.
• What happens to checkpoint cleanup if cursor walks stop instantiating those internals — does cleanup still bound space, or does the skip create a new leak window.

Expected outcome

• A decision: skip on ASC, skip in a restricted ASC case, or leave ASC internals unskipped.
• If skip is viable, either implement it or split an implementation ticket that also covers block reclamation.
• If not, close this with the analysis. Do not land an ASC skip that only avoids I/O and leaves extents allocated.