Tracking issue for the REST pagination total-count feature so we can attach priority and track its dependencies.
What
Let REST collection queries return the total number of matching records for pagination, opt-in via the Prefer request header, surfaced in RFC 7233-style response headers (Content-Range: items <start>-<end>/<total>, Range-Unit, Preference-Applied).
Prefer: count=estimated — cheap planner/table estimate; the safe default.Prefer: count=exact — precise, but scans the full matched set, so it is opt-in per REST mount via rest: { exactCount: true } (default off). Otherwise served as an estimate.- GET/HEAD only; requires a bounded
limit(); exact scans are bounded by a row cap + wall-clock budget.
Initial implementation: #2147.
Dependency / follow-up
Estimated counts are only as good as our range-count estimation. Accurate estimates for range conditions (>, <, BETWEEN, starts_with, etc.) depend on better cardinality estimation in the storage engine — see HarperFast/rocksdb-js#311. Until then, count=estimated falls back to Content-Range: .../* (unknown) for conditions with no cardinality estimate.
Worth deciding whether improved range estimation should be a prerequisite for broader rollout / enabling exact by default.
Docs
HarperFast/documentation#623
Tracking issue for the REST pagination total-count feature so we can attach priority and track its dependencies.
What
Let REST collection queries return the total number of matching records for pagination, opt-in via the
Preferrequest header, surfaced in RFC 7233-style response headers (Content-Range: items <start>-<end>/<total>,Range-Unit,Preference-Applied).Prefer: count=estimated— cheap planner/table estimate; the safe default.Prefer: count=exact— precise, but scans the full matched set, so it is opt-in per REST mount viarest: { exactCount: true }(default off). Otherwise served as an estimate.limit(); exact scans are bounded by a row cap + wall-clock budget.Initial implementation: #2147.
Dependency / follow-up
Estimated counts are only as good as our range-count estimation. Accurate estimates for range conditions (
>,<,BETWEEN,starts_with, etc.) depend on better cardinality estimation in the storage engine — see HarperFast/rocksdb-js#311. Until then,count=estimatedfalls back toContent-Range: .../*(unknown) for conditions with no cardinality estimate.Worth deciding whether improved range estimation should be a prerequisite for broader rollout / enabling exact by default.
Docs
HarperFast/documentation#623