Summary

• Eliminate unnecessary SQL round-trips across the task dispatch and completion hot paths, cutting dispatch_no_groups_500 latency by ~23% (166ms → 128ms)
• Replace generic chrono datetime parser with a fixed-position byte parser for the known SQLite format
• Add has_hierarchy fast-path flag (following existing has_tags pattern) to skip the active_children_count query when no parent-child tasks exist
• Batch dependency resolution from 2+2N queries down to 2 using DELETE … RETURNING + single UPDATE … RETURNING
• Add fast_dispatch mode that uses pop_next() (1 SQL) instead of peek_next() + gate + claim_task() (2 SQL) when no groups, pressure sources, or module caps are configured

Details

1. Inline last_insert_rowid (store/lifecycle/mod.rs)

insert_history was issuing a separate SELECT last_insert_rowid() query after every INSERT into task_history. The SqliteQueryResult already carries this value — use result.last_insert_rowid() directly, matching the existing pattern in complete_inner.

2. Fast datetime parsing (store/row_mapping.rs)

parse_datetime was calling chrono::NaiveDateTime::parse_from_str with a fallback — a generic parser invoked 2-4× per row_to_task_record. Replaced with a fixed-position byte parser that handles both "YYYY-MM-DD HH:MM:SS" and "YYYY-MM-DD HH:MM:SS.fff…".

3. has_hierarchy flag (store/mod.rs, scheduler/spawn/completion.rs)

handle_success was calling active_children_count (a SELECT COUNT(*) query) for every task completion, even when no tasks use parent-child hierarchy. Added an Arc<AtomicBool> flag to TaskStore — set to true when a task with parent_id is submitted — and skip the query when false. Follows the existing has_tags pattern exactly.

4. Batched dependency resolution (store/dependencies.rs)

resolve_dependents_inner previously used SELECT + DELETE + per-dependent COUNT + UPDATE (2+2N queries). Now uses DELETE FROM task_deps … RETURNING task_id followed by a single UPDATE tasks … WHERE id IN (…) AND NOT EXISTS (SELECT 1 FROM task_deps …) RETURNING id — always 2 queries regardless of fan-out. Applied the same DELETE … RETURNING optimization to fail_dependents_inner.

5. Fast dispatch path (scheduler/run_loop.rs, scheduler/builder.rs)

When no groups, pressure sources, resource monitoring, or module caps are configured, try_dispatch now uses pop_next() (atomic UPDATE+RETURNING, 1 SQL) instead of peek_next() + gate.admit() + claim_task() (2 SQL). Added an expiry filter to pop_next()'s inner SELECT so expired tasks are safely skipped. The slow path is preserved unchanged as a fallback.

Benchmark results