Skip to content

Fix ~1s slowdown on large query results - #67

Merged
eddietejeda merged 1 commit into
mainfrom
fix-result-poll-latency
Oct 24, 2026
Merged

eddietejeda merged 1 commit into
mainfrom
fix-result-poll-latency

Conversation

@eddietejeda

Copy link
Copy Markdown
Contributor

Summary

#66 started honoring Retry-After while polling GET /v1/results/{id}. The API sends Retry-After: 1 while a result is persisting, but persistence usually finishes ~100ms later, so every result too large to inline waited an extra second.

This goes back to the 50ms → 2s backoff for result polling. Retry-After is still honored for 429 retries.

Benchmark (live API, through Grafana, v1.0.4 vs this branch, median)

Query v1.0.4 #66 this PR
Full table, 56k rows × 20 cols 552ms 1583ms 590ms

Other queries are unaffected; results were identical to v1.0.4 in every case.

Testing

  • go test ./pkg/... (the test server now sends Retry-After: 1; the suite still runs in ~0.4s).

The Results API answers 202 with Retry-After: 1 while a result persists, but
persistence usually finishes ~100ms later. Honoring it made results too large
to inline ~1s slower than v1.0.4 (1583ms vs 552ms median for a 56k-row query).
Keep the 50ms backoff instead.
@eddietejeda
eddietejeda requested a review from a team as a code owner October 24, 2026 22:44
@eddietejeda
eddietejeda requested review from shefeek-jinnah and removed request for a team October 24, 2026 22:44
@eddietejeda
eddietejeda merged commit 4509c6e into main Oct 24, 2026
11 checks passed
@eddietejeda
eddietejeda deleted the fix-result-poll-latency branch October 24, 2026 22:51
@eddietejeda eddietejeda mentioned this pull request Oct 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant