Historical repository record migrated on 2026-10-10. Original repository path: docs/experiments/benchmarks/performance-frontier-labs/query.md Original SHA-256: 29be35ee90cc4c9ef93766ed000306be1054badb05167c3b28e315bcacfa8638 Stated outcomes, measured revisions, failures and limits remain historical. Local raw evidence is private and is not uploaded. Relative links and the data-drive prefix were normalized.

Query and availability lab packet

PI: query_landscape (GPT-6.1-SOL medium). State: source review complete; experiments proposed, not run. Shared plan and controls. Owned preparation paths: this packet and future query-frontier-* protocols; implementation changes require a separately admitted task.

Q3: distinguish source traversal from output cost

Question: why does broad-tail latency remain similar after Walk reduces heap? H1: loose timestamp bounds force traversal, or result construction dominates. H0: neither factor materially explains the plan difference.

Reuse the corrected 65536-row fixture with fixed row identities/content/seed; vary physical ordering (ordered versus shuffled timestamps) and first-page limit (100 versus 10000). Compare Scan/Walk with empty, selective and broad queries. Freeze the shuffle seed and exact requests before registration. Hold total history, payload and output contract fixed. Grade every complete chain outside first-page timing. No cold-cache claim.

Measure visited blocks/groups, decoded bytes, retained candidates, returned rows/bytes, phase CPU/wall, heap and allocations. Separate source loading, selection, JSON-value construction and serialization; current execution spans include construction, so existing phase totals cannot establish its exclusive cost. Primary timing uses plain builds; diagnostic counters run separately.

Discriminator: ordered input stopping early while shuffled input visits nearly every block rejects the idea that small pages inherently make Walk cheap. Constant source work with cost scaling with output bytes favors output work. Stop expanding this matrix if neither factor explains a reproducible difference; review phase evidence before proposing any code change.

Source: query.rs::sources, sources_walk, threshold loops and log_json; tail.rs::visit_block; completion_query_probe.rs; completion/profile.py. Existing exact-query oracle remains authoritative, not plan agreement alone.

Q4: amortization and concurrent demand

H1: pending blocks and index rebuilds erase part of Walk's warm benefit, while shared source-state locking limits concurrent gains. H0: cost and latency remain stable across those states at matched work.

First compare incomplete and completed tail blocks at the default 4096-record boundary, plus a restarted process, with fixed offered query cadence and ingress. Measure index-build CPU, pending/block bytes, first versus subsequent latency, persistent RSS and ACK interference. Then screen one versus four concurrent clients at the SAME aggregate offered query schedule, recording queue delay and completion rate. Do not confuse four times the demand with lock contention. Only add a diagnostic block-size ablation if the boundary screen supports H1.

Counterexamples: repeated extraction of incomplete entries outweighs Walk's pruning benefit; startup rebuilding pins substantial memory; source-loading serialization dominates at four clients. A process restart leaves OS cache warm. Publication pause/restart checks from R3 must precede reliance on transition answers. Full-chain, gaps, retention and snapshot invariants remain fixed.

Deliverables: registered commands/fixture, raw phase and exact-answer receipts, paired results by lifecycle/query kind, one supported optimization or a null result. PI reviews a bounded Luna fixture/counter inventory (estimated 1500 tokens) only when necessary. Total lab workload allocation is at most 90 minutes within the shared four-hour screen, never parallel with another lab workload.