Review query plans for supported high-cardinality filters
A permitted filter scans every shipment despite bounded page size.
- Focused work estimate
- 4h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- PostgreSQL · Performance
Estimated field mix
- Database engineering60%
- Performance engineering40%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional logistics platform lists shipments for partner dashboards. Offset pagination duplicates records during updates, while unrestricted filters create expensive database queries.
Setup prerequisites
- Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- BAPIPAGE-101 · Define supported shipment filters and their exact semantics
- BAPIPAGE-102 · Validate bounded sort options instead of accepting SQL fragments
- BAPIPAGE-103 · Enforce tenant scope before applying user filters
- BAPIPAGE-104 · Encode opaque cursors bound to the normalized query
- BAPIPAGE-105 · Use keyset traversal for shipments sharing timestamps
- BAPIPAGE-107 · Bound total-count work independently of result pagination
Acceptance criteria
- Capture plans against a declared synthetic dataset.
- Check indexes for supported filter/sort combinations.
- Report dataset size, cache state, and machine limits.
Implementation constraints
- Local query plans are evidence for the fixture, not production latency guarantees.
Verification to include
- Measure a selective and broad query.
- Identify a missing-index case and compare the corrected plan.
Deliverables
- Query-plan review.
Rollout and recovery
Add indexes through migrations; retain a rollback plan for index changes.
Value of the work
For the engineer: Practice cursor design, query contracts, and consistency/performance tradeoffs.
For the team: Provide predictable list APIs that remain bounded and preserve tenant scope.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.