core: speed up the analysis catalog with prepared statements

[kyleconroy]

A performance pass on the new core analyzer (internal/core), the one backing ClickHouse and GoogleSQL.

What was slow

The core catalog backs every lookup with a query against its in-memory SQLite database, and handed the raw *sql.DB to the generated catalogdb queries. database/sql prepares and discards a statement per call, so SQLite re-parsed and re-planned the same dozen queries thousands of times per run.

Profiling analyzer.Prepare put 65% of samples inside sqlite3Parser and 85% under database/sql dispatch — the analyzer itself was barely on the profile. Every column reference, type name, operator resolution and attribute decoration was a round trip that recompiled its SQL from text.

Changes

• Prepare each catalog statement once and rebind it, for both the dialect seed path and the analyzer's lookups.
• Install dialect seeds in a single transaction, and drop journalling for a database that is rebuilt from scratch on every run.
• Pin the pool to one connection. Each ":memory:" connection is its own empty database, so a second one would have seen a catalog with no tables in it — a latent bug under any concurrent use.
• Analyzer allocations: resolving a column no longer allocates a candidate slice per reference, the scope holds the catalog's column list instead of copying it into a scope-local type, a target's field list is flattened once instead of three times, and parameters are tracked by value.

Results

Analyzing a generated project of 20 tables and 5 statement shapes per table, best of 9 interleaved runs:

	before	after
sqlc analyze, 100 queries	58 ms	34 ms
sqlc analyze, 500 queries	181 ms	82 ms
catalog + dialect seed	6.00 ms	2.86 ms
analysis, 5 statements (warm catalog)	1,579 µs	398 µs

Output is byte-identical to main on both GoogleSQL and ClickHouse.

What this deliberately does not do

Lookup volume is unchanged at 13 catalog queries per statement, and analysis still allocates ~400 times per statement — nearly all of it database/sql scanning a row per lookup, which prepared statements don't touch.

Memoizing lookups removes both (0 queries, 48 allocations per 5 statements, another 2× end to end). It was prototyped and dropped: it needs cache invalidation on every mutation plus an unwritten contract that callers must not mutate the slices ClassColumns, FindOperators and FindProcs hand back. That didn't seem worth it for lookups against an in-memory database. Easy to revisit if the core path's allocation profile ever matters.

For context, per query excluding parsing, the core analyzer now sits at ~122 µs against ~80 µs for the original PostgreSQL path and ~52 µs for MySQL — still the slower path, down from ~234 µs before this change.

Tests

No new tests. Behaviour is covered by the existing end-to-end tests — analyze_basic, analyze_select and analyze_dml exercise both dialects through TestReplay, which passes, as does the full suite.

internal/core/analyzer/bench_test.go adds the benchmarks quoted above. It contains no tests, only benchmarks, so it does not run under go test.