fix: pair (schema, table) as composite in getTotalRowCount

[veksen]

Summary

• getTotalRowCount deduplicated schemas and tables into separate arrays and paired them positionally via unnest($1, $2). For the common case of one schema with N tables, Postgres padded the shorter schema array with NULL, dropping every table past the first from the JOIN — so SUM(reltuples) came from a single table.
• In production this caused a 300K-row table to report as 77 rows (the first table in the list was a small audit table), pushing decideStatsStrategy through the 10k-row default instead of dumpSourceStats and silently degrading optimization for the whole source.
• Fix: match composite (nspname, relname) pairs from position-aligned non-deduplicated arrays via = ANY(SELECT s, t FROM unnest(...)), so every requested table contributes exactly once.

Test plan

Five testcontainer integration tests in src/sync/pg-connector.test.ts, each guarding a specific incorrect implementation shape. Every test asserts the exact expected sum (toBe(...)) — reltuples after ANALYZE on uniformly-inserted rows is exact at these sizes (all tables below the sampling threshold).

• single schema, multi-table — direct repro of the Slack bug. Verified to fail on pre-fix code with expected 77 to be 300077.

• uneven table counts across schemas — 3 tables (1K/2K/4K) across 2 schemas, where the pre-fix dedup shrinks schemaNames below tableNames and NULL-pads the tail. Verified to fail on pre-fix code with expected 1000 to be 7000.

• request-set scoping — a 500K unwanted table in the same schema must not leak into the sum.

• composite pair vs. cross-product — guards against a cartesian re-implementation (n.nspname = ANY($1) AND c.relname = ANY($2)). With public.{x,y} and reporting.{x,y} all present but only (public.x, reporting.y) requested, a cartesian impl would wrongly count public.y and reporting.x. Verified: cartesian variant yields 130300 instead of 300.

• duplicate input — passing the same (schema, table) pair twice must not double-count. Guards against a JOIN unnest(...) re-implementation that multiplies each catalog row by the number of matching input rows. Verified: JOIN variant yields 10000 instead of 5000.

• npx tsc --noEmit clean.

• All 7 tests pass in src/sync/pg-connector.test.ts.

Out of scope (separate finding)

PgIdentifier.toString() applies quote_ident semantics, so a mixed-case table name like "Foo" produces the quoted form "Foo" with double quotes. pg_class.relname stores the raw unquoted name (Foo), so getTotalRowCount will miss any mixed-case or reserved-word table. This is pre-existing behavior, not a regression from this fix — worth a separate ticket if it matters in practice.

🤖 Generated with Claude Code

[github-actions]

Query Doctor Analysis

View full run details

2 queries analyzed

2 pre-existing issues

• SELECT "guests"."id", "guests"."session_id", "guests"."username", "guests"."avatar_path", "guests"."color", "guests"."side", "guests"."audio_recording_path", "guests"."audio_recording_public", "gue...
  index assets(event_id, inserted_at desc)
  cost 31,003,449 → 1,493 (100% reduction)
• SELECT * FROM guest_ip_addresses WHERE ip_address = '127.0.0.1';
  index guest_ip_addresses(ip_address)
  cost 154,402 → 8 (100% reduction)

_{Using assumed statistics (10000000 rows/table). For better results, sync production stats.}