/**
 * Index warm-up worker thread.
 *
 * Every measurement below is from the reference VM's production databases
 * (2.5 GB metadata / 1.19 M symbols, 630 MB labels / 1.42 M rows), each taken
 * cold and then repeated warm:
 *
 *   idx_symbols_name, covering scan   83 s cold  →  0.11 s warm
 *   idx_type_name, covering scan      33 s cold  →     (same shape)
 *   labels ⋈ label_files, one locale  31 s cold  →     (same shape)
 *
 * Those three are the whole of the latency the benchmark keeps re-measuring:
 * run d79f62a3 (2026-08-17) spent 189 s on one `search` batch, 174 s on the
 * session's first `labels(action="search")` and 33 s on a `get_object_info`
 * that its own report timed at 4.8 s — 87 % of a 23-minute run was tool time,
 * and the queries themselves are milliseconds once the pages are in the OS
 * cache. Nothing about the SQL is slow; the first reader of each index pays for
 * the whole file being cold.
 *
 * So pay it before the user does, on a thread that cannot block the event loop.
 * The OS page cache is process-wide, so warming it here warms it for the
 * server's own connections — the work does not have to happen on them.
 *
 * What it is not: permanent. The two databases together are larger than the
 * cache they compete for on the reference VM — a full warm-up measured 102 s
 * end to end, and a scan of the symbol name index that had cost 0.11 s was back
 * to 46 s after a build had read enough to evict it. Warming at startup buys the
 * session's first questions, which is what the benchmark measures; it does not
 * buy the whole session.
 *
 * Spawned by warmIndexes(); posts one message per step and a final summary.
 */
export interface WarmupStep {
    /** Reported back to the parent, and the name a slow step is blamed on. */
    name: string;
    /** Which database the step reads. */
    db: 'symbols' | 'labels';
    /**
     * A COUNT over an explicitly named index. `INDEXED BY` is not a hint here but
     * the point of the query: without it SQLite is free to answer the count off
     * whichever index is smallest, warming one nothing else reads.
     */
    sql: string;
}
export interface WarmupMessage {
    type: 'step' | 'done' | 'error';
    name?: string;
    ms?: number;
    rows?: number;
    totalMs?: number;
    error?: string;
}
/**
 * In descending order of what the benchmark actually waits on, because the
 * budget cuts from the end.
 *
 *  - idx_symbols_name backs the substring fallback in searchSymbols and every
 *    prefix lookup: 83 s for the first one on a cold cache.
 *  - the labels join is what `labels(action="search")` pays after FTS has
 *    already answered in 2 ms.
 *  - idx_type_name backs every type-filtered search and get_object_info.
 *  - the FTS steps pull the postings lists for tokens that appear in most
 *    English label texts, which is the part of the FTS b-tree a phrase search
 *    walks.
 */
export declare const WARMUP_STEPS: WarmupStep[];
//# sourceMappingURL=indexWarmupWorker.d.ts.map