Skip to content

feat(api): estimate large v3 list counts instead of capping at 10k#1508

Open
andrewklau wants to merge 1 commit into
mainfrom
fix/v3-count-estimates
Open

feat(api): estimate large v3 list counts instead of capping at 10k#1508
andrewklau wants to merge 1 commit into
mainfrom
fix/v3-count-estimates

Conversation

@andrewklau

Copy link
Copy Markdown
Contributor

No description provided.

@andrewklau andrewklau force-pushed the fix/v3-count-estimates branch from 999c641 to a39eb19 Compare June 17, 2026 21:04
The v3 multichain, staking, account-staking and nft-token count endpoints
only summed an exact COUNT capped at maxQueryCount, so any large result set
rendered as "10,000+" even when the true total is in the millions.

Add a shared `countFromEstimate` helper in libs/response.ts (sibling to
countFromCagg) that takes a cheap query-planner estimate via
count_cost_estimate() and, when the query is both expensive and large
(cost > maxQueryCost and rows > maxQueryRows), returns the rounded estimate
as an approximate count; otherwise it falls back to the existing exact
capped count. Each endpoint now calls the helper instead of repeating the
estimate plumbing inline.

Adds a <name>Estimate.sql per endpoint (bare filtered SELECT, no LIMIT and
no rolling-window upper bound) so EXPLAIN's top-node row estimate reflects
the matching-row count. count_cost_estimate already exists in each target
database (indexer-signature/-staking/-events), so no migration is needed.
@andrewklau andrewklau force-pushed the fix/v3-count-estimates branch from a39eb19 to 50fbe7a Compare June 17, 2026 21:15
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