✔ 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 Trap
Business 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:

Pipeline Latency Distribution (Total Plan Time: 500.71 ms) Nodes consuming ≥ 20% of query runtime are highlighted with glowing borders
📐 PROJECTION 0.0%
Latency: 0.00 ms
Rows In/Out: 1
Data Vol: 16 B
📁 Projections: peak_concurrent_wor...
📊 UNGROUPED_AGGREGATE 0.2%
Latency: 1.14 ms
Rows In/Out: 1
Data Vol: 16 B
📐 PROJECTION 0.0%
Latency: 0.05 ms
Rows In/Out: 998,852
Data Vol: 15.24 MB
📁 Projections: concurrent_workers
📐 PROJECTION 0.0%
Latency: 0.05 ms
Rows In/Out: 998,852
Data Vol: 15.24 MB
📁 Projections: concurrent_workers
📐 PROJECTION 0.0%
Latency: 0.23 ms
Rows In/Out: 998,852
Data Vol: 38.10 MB
📁 Projections: ['#0', '#1', '#2']
🪟 WINDOW 🔥 55.9% Cost
Latency: 280.08 ms
Rows In/Out: 998,852
Data Vol: 38.10 MB
📁 Projections: sum(net_change) OVE...
⚠️ Heavy Execution Bottleneck (55.9% of query runtime)
📊 HASH_GROUP_BY 🔥 43.3% Cost
Latency: 216.64 ms
Rows In/Out: 998,852
Data Vol: 22.86 MB
⚠️ Heavy Execution Bottleneck (43.3% of query runtime)
📐 PROJECTION 0.0%
Latency: 0.18 ms
Rows In/Out: 2,000,000
Data Vol: 22.89 MB
📁 Projections: ['event_time', 'cha...
⚙️ UNION 0.0%
Latency: 0.00 ms
Rows In/Out: 0
Data Vol: 0 B
📐 PROJECTION 0.0%
Latency: 0.24 ms
Rows In/Out: 1,000,000
Data Vol: 11.44 MB
📁 Projections: ['event_time', 'cha...
🔍 TABLE_SCAN 0.2%
Latency: 0.96 ms
Rows In/Out: 1,000,000
Data Vol: 7.63 MB
📁 memory.main.staff_shifts
📐 PROJECTION 0.0%
Latency: 0.23 ms
Rows In/Out: 1,000,000
Data Vol: 11.44 MB
📁 Projections: ['event_time', 'cha...
🔍 TABLE_SCAN 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 Highlighted
Candidate SQL Executed by gemini-3.8-flash-low (Runtime on 1M Rows: 157.34 ms)
WITH 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;
Golden Reference Ground Truth SQL (Runtime on 1M Rows: 113.51 ms)
-- 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;
DuckDB Fixture Setup DDL & Data Population
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
← Prev: E-Commerce Financial Aggr... ⊞ Back to Benchmark Dashboard Next: Continuous Asset Lease Un... →