Patent-pending · zero-scan
The database that never reads your data
Most of the columns in a real table aren’t data — they’re a function: autoincrement ids, evenly-spaced timestamps, accumulating and reset counters, sequences. AT-1 recovers the function behind the column and answers a range predicate and its exact selectivity from a few coefficients — in microseconds, touching zerostored bytes. It isn’t a faster scan. It’s a different physics of query.
- 30,361×
- autoincrement id, selective range vs full scan
- 61,770×
- evenly-spaced timestamp predicate
- 0 bytes
- stored values read on the pure analytic path
- = DuckDB
- byte-identical results, DuckDB as oracle
Two optimizer primitives
- Column profiler + exact selectivity. Each integer column is profiled once into its generative structure — constant, arithmetic, quadratic (polynomial-in-index), or piecewise (reset counters, gapped timestamps, slope-changing ramps, profiled per segment) — yielding an O(1) exact per-predicate selectivity with no histogram, sample, or scan. The optimizer plans joins on truth, not an estimate.
- Analytic query. When a predicate is an analytic generator, the executor computes the exact matching row set from the closed form: the pure path (predicate + projection both analytic) reads zero blocks; the mixedpath reads opaque projected columns from only the row-groups the matched rows fall in. Because per-block sizes are in the footer, EXPLAIN's predicted bytes equal the bytes actually read.
Honest boundaries
The win is real precisely because it’s bounded. Selective predicates on generated columns are the 30,000×+ case; wide, low-selectivity bands are materialization-bound (~60×) — but the exact selectivity is still free, which is the real optimizer prize. Scrambled generators (an LCG or LFSR whose range scatters across the index) are profiled for cardinality and point-membership but fall back to a normal scan for ranges — correct, just not accelerated. Every result is validated byte-identical against DuckDB on the same data; nothing here is approximate.
Delivered through the managed AT1DB engine. It’s the query-layer counterpart of the AT-1 thesis: don’t store the data, store the generator — then evaluate it instead of scanning it.