Course overview/Run it repeatedly3 of 4
Date filters and query cost
Date filters and query cost
Compare two date filters and learn what a small local scan can and cannot tell you about cost.
Write filters the engine can use
ordered_at >= '2024-01-01' AND ordered_at < '2025-01-01' gives the engine a clear range. YEAR(ordered_at) = 2024 applies a function to every row and may stop it from skipping rows outside the range. The same issue appears with LOWER(email). This property is often called sargability, but the important idea is simple: write the filter so the engine can use the column directly. DuckDB can show local plans and rows scanned, but this small project is not a warehouse-cost benchmark.
Bytes scanned are a BigQuery billing unit, and warehouse examples are not local measurements. Agents can also create an N+1 pattern - one query to get a list, followed by one query per item - or run too many exploratory queries. Use --limit and set a query budget before profiling.
Your task
Run each single-statement worksheet, capture the exact rows scanned printed by your installed DuckDB for both forms in docs/sargability.md, and explain why the numbers are local evidence only. Use at most three query invocations and include the --description command used for each.
Check your understanding
- Why is a half-open date range a good filter?
- Does DuckDB's scan count equal a BigQuery bill?
- What is an N+1 query pattern, and why can it be expensive?
Do it with your agent
Say next lesson, set the query budget, run the comparison, then say review my work.
Rubric
- Shows both filters and the exact scan counts from the installed DuckDB version, with the version recorded.
- States which form scans fewer rows in this run and explains the difference without claiming warehouse billing equivalence.
- Records a query budget of 3 or fewer and uses
--limitfor exploration.