Background

Design: WRITING-39975. Scope: WRITING-39974. Epic: SPM-4886. Related: WT-18159, WT-18790.

Today a follower remove on a layered table can open the stable table in two places: when the cursor operation starts, and when the ingest lookup misses. Both reads are slow and fill the cache with pages the follower may not need. With blind_remove set, a follower remove must skip both and never open the stable table.

Change

The decision is made from the ingest table alone:

• The key is in ingest: remove it as usual.
• Ingest shows the key is already deleted, either through a delete for the key or a truncate that covers it: return success. Nothing is written.
• Ingest knows nothing about the key: write a delete for the key into ingest without reading stable, and return success.

Transactions, visibility, timestamps and cursor position behave as for any other remove. Write conflicts and prepare conflicts still come from the ingest table and are still reported.

Statistics

Added in the same PR:

• layered_curs_blind_remove_follower: layered table cursor blind remove operations on a follower.
• layered_curs_blind_remove_ingest_deleted: layered table cursor blind remove operations on a key already deleted in the ingest btree.

Tests

Python tests in the same PR cover:

• Each of the three ingest cases above, and that the stable table is never opened (check the stable-open statistic).
• A remove of a key that exists only in stable is recorded in ingest and the key is gone after reads and after step-up.
• Rollback on a write conflict and prepare conflict reported from ingest.
• Truncate covering the key.
• Both new statistics move in the expected direction.

Acceptance criteria

• A follower blind remove never opens the stable table.
• Behaviour matches the design for all three ingest cases.
• New tests pass, and fail without the change.

Depends on

The blind_remove option ticket.