✔ PASS
Temporal & Time-Series
task_020_Q20_interval_overlap_concurrency
Scaled: 1M+ Records
Ordered: Yes
Peak Concurrent Workforce Capacity via Interval Overlap Scan
Candidate Latency (1M Rows)
157.34 ms
(1.4x slower than golden)
Golden Latency (1M Rows)
113.51 ms
DuckDB in-memory engine
Underlying Data Volume
1,000,000 rows
22.9 MiB across 1 table
Evaluated Model
gemini-3.8-flash-low
Gen Latency: 4.8s
✔ Correctness Verified on 1M+ Records
Candidate SQL output matches ground truth golden query across all multiset rows and numeric tolerances (tol=1e-3). Zero data skew or anti-patterns detected on full dataset scale.
1. Analytical Significance & What It Means
Scenario & Frontier TrapBusiness Scenario & Problem
Workforce managers must calculate maximum concurrent staffing levels from employee shift start and end times to ensure warehouse safety limits are never breached.
⚡ The Frontier Trap (Why LLMs Fail)
Pairwise self-joins between overlapping shifts blow up to O(N^2) complexity.
Prompt / User Request Given to Model
Workforce managers must calculate maximum concurrent staffing levels from employee shift start and end times to ensure warehouse safety limits are never breached. Execute the required analytical SQL calculation in DuckDB. Expected output columns: peak_concurrent_workers. Results should be ordered as specified.
2. Underlying Tables, Row Counts & Data Volume
1 Tables (1,000,000 rows • 22.9 MiB)Production-scale fixtures loaded into the isolated DuckDB sandbox with at least 1,000,000 records per table:
📊 staff_shifts
1,000,000 rows
22.9 MiB Data Volume
shift_id (INTEGER) worker_id (INTEGER) start_time (TIMESTAMP) end_time (TIMESTAMP)Data Preview (showing sample rows from 1,000,000 total rows):
| # | shift_id | worker_id | start_time | end_time |
|---|---|---|---|---|
| 1 | 1 | 101 | 2026-03-01 08:00:00 | 2026-03-01 12:00:00 |
| 2 | 2 | 102 | 2026-03-01 09:00:00 | 2026-03-01 13:00:00 |
| 3 | 3 | 103 | 2026-03-01 10:00:00 | 2026-03-01 11:30:00 |
| 4 | 3 | 103 | 2026-03-01 09:30:00.000001 | 2026-03-01 09:30:00.000001 |
| 5 | 4 | 104 | 2026-03-01 09:30:00.000028 | 2026-03-01 09:30:00.000028 |
| 6 | 5 | 105 | 2026-03-01 09:30:00.000044 | 2026-03-01 09:30:00.000044 |
| 7 | 6 | 106 | 2026-03-01 09:30:00.000072 | 2026-03-01 09:30:00.000072 |
| 8 | 7 | 107 | 2026-03-01 09:30:00.000081 | 2026-03-01 09:30:00.000081 |
| 9 | 8 | 108 | 2026-03-01 09:30:00.000107 | 2026-03-01 09:30:00.000107 |
| 10 | 9 | 109 | 2026-03-01 09:30:00.000120 | 2026-03-01 09:30:00.000120 |
| 11 | 10 | 110 | 2026-03-01 09:30:00.000143 | 2026-03-01 09:30:00.000143 |
| 12 | 11 | 111 | 2026-03-01 09:30:00.000160 | 2026-03-01 09:30:00.000160 |
| 13 | 12 | 112 | 2026-03-01 09:30:00.000192 | 2026-03-01 09:30:00.000192 |
| 14 | 13 | 113 | 2026-03-01 09:30:00.000207 | 2026-03-01 09:30:00.000207 |
| 15 | 14 | 114 | 2026-03-01 09:30:00.000223 | 2026-03-01 09:30:00.000223 |
3. Graphical Query Execution Plan & Cost Bottlenecks
Physical Operator Tree (DuckDB 2.0 Profiler)Visual flowchart of the physical execution pipeline. Operators with high relative costs (≥ 20% of query runtime or heavy latency) are visually highlighted:
0.0%
Latency: 0.00 ms
Rows In/Out: 1
Data Vol: 16 B
📁 Projections: peak_concurrent_wor...
0.2%
Latency: 1.14 ms
Rows In/Out: 1
Data Vol: 16 B
0.0%
Latency: 0.05 ms
Rows In/Out: 998,852
Data Vol: 15.24 MB
📁 Projections: concurrent_workers
0.0%
Latency: 0.05 ms
Rows In/Out: 998,852
Data Vol: 15.24 MB
📁 Projections: concurrent_workers
0.0%
Latency: 0.23 ms
Rows In/Out: 998,852
Data Vol: 38.10 MB
📁 Projections: ['#0', '#1', '#2']
🔥 55.9% Cost
Latency: 280.08 ms
Rows In/Out: 998,852
Data Vol: 38.10 MB
📁 Projections: sum(net_change) OVE...
🔥 43.3% Cost
Latency: 216.64 ms
Rows In/Out: 998,852
Data Vol: 22.86 MB
0.0%
Latency: 0.18 ms
Rows In/Out: 2,000,000
Data Vol: 22.89 MB
📁 Projections: ['event_time', 'cha...
0.0%
Latency: 0.00 ms
Rows In/Out: 0
Data Vol: 0 B
0.0%
Latency: 0.24 ms
Rows In/Out: 1,000,000
Data Vol: 11.44 MB
📁 Projections: ['event_time', 'cha...
0.2%
Latency: 0.96 ms
Rows In/Out: 1,000,000
Data Vol: 7.63 MB
📁 memory.main.staff_shifts
0.0%
Latency: 0.23 ms
Rows In/Out: 1,000,000
Data Vol: 11.44 MB
📁 Projections: ['event_time', 'cha...
0.2%
Latency: 0.91 ms
Rows In/Out: 1,000,000
Data Vol: 7.63 MB
📁 memory.main.staff_shifts
| Operator | Cost % | Latency | Processed Rows | Data Volume | Details / Table | Status |
|---|---|---|---|---|---|---|
| WINDOW | 55.9% | 280.08 ms | 998,852 | 38.10 MB | Projections: sum(net_change) OVER (ORDER BY even | 🔥 BOTTLENECK |
| HASH_GROUP_BY | 43.3% | 216.64 ms | 998,852 | 22.86 MB | - | 🔥 BOTTLENECK |
| UNGROUPED_AGGREGATE | 0.2% | 1.14 ms | 1 | 0.00 MB | - | Normal |
| TABLE_SCAN | 0.2% | 0.96 ms | 1,000,000 | 7.63 MB | memory.main.staff_shifts | Normal |
| TABLE_SCAN | 0.2% | 0.91 ms | 1,000,000 | 7.63 MB | memory.main.staff_shifts | Normal |
| PROJECTION | 0.0% | 0.24 ms | 1,000,000 | 11.44 MB | Projections: ['event_time', 'change_val'] | Normal |
| PROJECTION | 0.0% | 0.23 ms | 998,852 | 38.10 MB | Projections: ['#0', '#1', '#2'] | Normal |
| PROJECTION | 0.0% | 0.23 ms | 1,000,000 | 11.44 MB | Projections: ['event_time', 'change_val'] | Normal |
| PROJECTION | 0.0% | 0.18 ms | 2,000,000 | 22.89 MB | Projections: ['event_time', 'change_val'] | Normal |
| PROJECTION | 0.0% | 0.05 ms | 998,852 | 15.24 MB | Projections: concurrent_workers | Normal |
| PROJECTION | 0.0% | 0.05 ms | 998,852 | 15.24 MB | Projections: concurrent_workers | Normal |
| PROJECTION | 0.0% | 0.00 ms | 1 | 0.00 MB | Projections: peak_concurrent_workers | Normal |
| UNION | 0.0% | 0.00 ms | 0 | 0.00 MB | - | Normal |
4. Queries Executed (Candidate vs Golden Ground Truth)
Beautified & Syntax HighlightedWITH EVENTS AS
(SELECT start_time AS event_time,
1 AS change_val
FROM staff_shifts
UNION ALL SELECT end_time AS event_time,
-1 AS change_val
FROM staff_shifts), timeline AS
(-- If shifts can end exactly when another starts, handle ordering:
-- In standard concurrency calculations, whether end is inclusive or exclusive matters.
-- Usually, interval is [start_time, end_time). If a shift ends at 12:00 and another starts at 12:00,
-- departing (-1) happens before arriving (+1) or at the exact instant.
-- When ordering by event_time, ordering -1 before +1 treats intervals as half-open [start, end),
-- or summing all changes at the exact same timestamp.
-- Grouping by event_time or summing over window:
SELECT event_time,
sum(change_val) AS net_change
FROM EVENTS
GROUP BY event_time),
running_total AS
(SELECT sum(net_change) OVER (
ORDER BY event_time ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS concurrent_workers
FROM timeline)
SELECT coalesce(max(concurrent_workers), 0) AS peak_concurrent_workers
FROM running_total;
-- Transform start/end intervals into delta events and compute peak concurrent staffing
WITH shift_events AS
(SELECT start_time AS event_time,
1 AS delta
FROM staff_shifts
UNION ALL SELECT end_time AS event_time,
-1 AS delta
FROM staff_shifts),
running_occupancy AS
(SELECT event_time,
sum(delta) OVER (
ORDER BY event_time, delta DESC) AS concurrent_workers
FROM shift_events)
SELECT max(concurrent_workers) AS peak_concurrent_workers
FROM running_occupancy;
CREATE TABLE staff_shifts (shift_id INT, worker_id INT, start_time TIMESTAMP, end_time TIMESTAMP);
INSERT INTO staff_shifts
VALUES (1, 101, '2026-03-01 08:00:00', '2026-03-01 12:00:00'),
(2, 102, '2026-03-01 09:00:00', '2026-03-01 13:00:00'),
(3, 103, '2026-03-01 10:00:00', '2026-03-01 11:30:00');
5. Query Results & Expected Ground Truth
Tabular Comparison
Actual Candidate Output
(1 rows × 1 cols)
| # | peak_concurrent_workers |
|---|---|
| 1 | 3 |
Expected Golden Output
(1 rows × 1 cols)
| # | peak_concurrent_workers |
|---|---|
| 1 | 4 |