You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Chooser: add storage-size fallback when stats are missing #78
PR #75 introduced a cost-based Volcano/Vectorized chooser that uses RowEstimator::estimate_scan_rows() to decide whether to use the Vectorized path. This function returns table.num_rows when stats are available, or 0 otherwise.
Problem
For newly created tables or tables that have not had ANALYZE TABLE run, num_rows is 0. The current chooser logic treats estimated_rows > kVectorizedRowThreshold as the Vectorized trigger. When estimated_rows == 0 (unknown), use_vectorized stays false, falling back to Volcano — which is correct for truly empty tables but misses an opportunity for large scans where stats are simply stale/missing.
A table that has 5 million physical rows on disk but hasn't been ANALYZEd would incorrectly fall back to the (slower) Volcano path.
Proposed Solution
When estimate_scan_rows() returns 0 or when the table has no stats, derive a fallback estimate from storage size:
Add a method to StorageManager or BufferPoolManager that returns the on-disk size or block count for a given table:
Alternatively, HeapTable::tuple_count() could be used as a non-stats-based row estimate — it traverses all pages and counts non-deleted tuples (expensive but accurate).
In the chooser block, when estimated_rows == 0 || !has_stats, fall back to:
Call storage size → compute rows as size_bytes / estimated_row_width (row width can be estimated from schema)
Or simply: treat missing stats as "assume large scan" → use_vectorized = true if table has any data
Compare the fallback estimate against kVectorizedRowThreshold to set use_vectorized.
Activity