Investigate which WiredTiger assumptions baked into the JOO cost model (join_cost_estimator_impl.cpp, join_estimates.cpp, catalog_stats.cpp, createCatalogStats() in executor.cpp) break under disaggregated storage and investigate if this can lead to poor plan quality.

Assumptions that could be wrong

• Random IO is 5.4x sequential IO. Disagg has no sequential locality.
• Per-page IO costs are ~160us sequential and ~864us random. join_start.py calibrated these on a local disk with the OS cache dropped. A hot GetPage on disagg takes about 1-5ms (5ms p95 SLO). Cold-tier collections read from S3 at about 100ms+ per page.
• A page is 32KB. Disagg collections use leaf_page_max=16KB (128KB for storageTier: cold). The size fallback still divides by kDefaultPageSizeBytes (32KB).
• approxNumLeafPages covers the whole collection. The layered stat cursor only counts the local ingest btree. The count is then ingest-only (far too low) or 0, which forces the size fallback.
• storageSize - freeStorageSize is the collection's on-disk size. On disagg it is the size of the stable checkpoint only (page images plus live deltas). Recent writes in the ingest table are left out, and freeStorageSize is always 0.
• The WT cache is the only buffer (the Mackert-Lohman b). Disagg adds the PALI block cache.
• A collection is one btree with uniform IO. A layered table keeps recent writes in a local ingest btree and everything else in the remote stable btree. Every lookup searches ingest, then stable. That costs extra CPU per document, which the 612ns/doc calibration does not include.

Related

SERVER-129082 (WT leaf page counter), SERVER-117620 (TODO: set pageSizeBytes), SERVER-139160 (join explain tests on disagg).