Adjust the data size, filter selectivity, and index design. Explore how those choices affect the estimated work required to answer a database query.
PostgreSQL-inspired · Deterministic model
01 / Define the workload
02 / Choose an index
Query being modeled
SELECT id, total, created_at FROM orders WHERE customer_id = 42 ORDER BY created_at DESC LIMIT 20;
03 / Estimated results
1,000,000
20
42.0 ms
10,000
Estimated rows examined
Lower is betterWhat changed?
Without an index, the model scans the whole table to find matching rows. The database then sorts the matching rows to return the requested page.
Estimated scan-work reduction
0%
Relative to the full-table-scan baseline.
Modeled latency change
Baseline
Model output, not a measured benchmark.
These estimates use a simplified work model. PostgreSQL chooses plans using statistics, cost parameters, available indexes, and other factors. Actual execution time must be measured against a real database.
01
A highly selective filter may make an index more attractive. A broad filter can change the planner's preferred strategy.
02
The composite index aligns the customer filter with the requested ordering, allowing the model to stop early.
03
Indexes consume storage and add write overhead. Optimize the workload as a whole, not just one query.