Index- und Join-Kostenschätzer

A pocket query planner. Enter table statistics and a selectivity, press the estimate button, and see which access path or join algorithm wins under a classic textbook cost model (page I/Os plus a small CPU term). The numbers are didactic — they match database course formulas, not Postgres or MySQL internals.

Access paths. A sequential scan costs one I/O per page. An unclustered index pays the tree height, the leaf pages that cover the matches, then roughly one random I/O per matching row. A clustered index replaces that last term with a contiguous page range. Unique equality can stop after one leaf. When selectivity is high, the scan usually wins; when it is low and an index exists, the index wins — that crossover is the whole point of the tool.

Joins. Nested loops (with optional index on the inner), block nested loops that keep B−2 outer pages in the buffer, in-memory or Grace hash join, and sort-merge with a simple external-sort cost. Join selectivity is the fraction of the Cartesian product that survives the predicate (for an equijoin on a key of S it is about 1/|S|).

Limits. No histograms, no bitmap indexes, no parallel operators, no cache hits, no network. Buffer size only affects block nested loops and whether the hash build spills.