perf: cache DDL constraint metadata on TableSchema instead of re-parsing per statement

[iheitlager]

Description

compile_insert (src/codegen/stmt/insert.rs:200) and compile_update_with_catalog (src/codegen/stmt/update.rs:80) both call parse_create_table(&schema.sql) on every single statement compile, re-tokenizing and re-parsing the table's full original CREATE TABLE text purely to recover constraint info (CHECK, PRIMARY KEY/AUTOINCREMENT) that TableSchema doesn't store structurally. This runs once per INSERT/UPDATE compile — i.e., once per single-row statement — and is a likely major contributor to a ~10x perf gap vs. the SQLite oracle on single-row insert/update benchmarks (insert_single: 14.9ms ours vs 1.85ms oracle).

Found via a 4-agent investigation into tests/performance/crud.rs/engine.rs benchmark regressions. Fsync frequency and journal discipline were separately ruled out as correct (matching SQLite's own 2-fsync-per-commit rollback-journal model).

Complexity

Estimate: small
Reasoning: Add a constraints/rowid-alias-autoincrement field to TableSchema (src/schema/ddl_reader.rs:71), populate it once in read_schema, and switch the two call sites to read it directly instead of re-parsing. Contained to schema loading + two codegen call sites; no grammar/parser surface change.

Context

Related to the tokenizer string-copy ticket (filed alongside this one) — the two compound, since each DDL re-parse also pays a full tokenizer string allocation.

Acceptance Criteria

• TableSchema carries parsed constraint/autoincrement metadata populated at read_schema time
• compile_insert/compile_update_with_catalog no longer call parse_create_table(&schema.sql) per statement
• insert_single/update_pk benchmarks in tests/performance/crud.rs show measurable improvement
• Existing oracle-parity/corpus tests still pass

[iheitlager]

Closed via #649.

Implemented with a design deviation: the cache couldn't live as a TableSchema field as originally proposed — src/schema/ddl_reader.rs must have zero dependency on src/parser (spec 002 Requirement 5, verified). Instead added a process-wide, content-addressed cache (cached_create_table) in the codegen layer, shared by compile_insert/compile_update_with_catalog.

Also worth recording: the acceptance criterion that insert_single/update_pk in tests/performance/crud.rs show measurable improvement did not hold up under measurement. parse_create_table costs ~5µs in isolation vs. ~14ms/iteration of I/O-dominated execution in those benchmarks (which also compile the program once, outside the timed loop). The premise that this reparse was a major contributor to the ~10x oracle gap doesn't hold — the cache is still correct and useful for workloads that compile the same schema repeatedly (e.g. exec.rs script mode), just not visible on that particular benchmark.

spend: matched estimate (small)

---

🤖 Analysis by Claude