Context
Epic 27 Theme 2 set a target of <2s for all vector endpoints at production scale (76k article corpus). During live validation against deployed loopctl.com, all vector endpoints hit the target:
But distant_pairs consistently runs ~7.85s — well above the 2s bar.
Current state
The endpoint is deliberately bounded (@max_pair_candidates 1000 + statement_timeout) and correctly returns partial results. It's not the full-scan failure mode the epic fought. The scale-gate asserts index-correctness, not latency, for this endpoint.
So: it's bounded and correct, just slow.
What's needed
- Confirm if the 1000 candidate bound and timeout values are optimal or conservative
- Profile the pairing logic to find low-hanging optimization (e.g., early termination, index hints, cache)
- Either confirm the sub-2s bar is unrealistic for corpus-wide pairing and update the AC, or find the latency sink
Not a blocker — the endpoint works and is bounded. But worth investigating if there's cheap optimization fruit, or if we need to adjust the Theme 2 target.
Context
Epic 27 Theme 2 set a target of <2s for all vector endpoints at production scale (76k article corpus). During live validation against deployed loopctl.com, all vector endpoints hit the target:
searchsemantic: 0.56ssearchcombined: 0.69ssuggested_links: 0.28s (after Verify follow-up (#168/#170): suggested_links STILL 500s in prod — unbounded full-corpus scan (scale), not param interpolation #172 improvements)novelty: 0.63sBut
distant_pairsconsistently runs ~7.85s — well above the 2s bar.Current state
The endpoint is deliberately bounded (@max_pair_candidates 1000 + statement_timeout) and correctly returns partial results. It's not the full-scan failure mode the epic fought. The scale-gate asserts index-correctness, not latency, for this endpoint.
So: it's bounded and correct, just slow.
What's needed
Not a blocker — the endpoint works and is bounded. But worth investigating if there's cheap optimization fruit, or if we need to adjust the Theme 2 target.