feat(advise): a Redshift workload adapter — sort and distribution keys, not indexes

[hanslemm]

Batch 3b, completing Batch 3. Adds a Redshift workload adapter: advise --engine redshift reads query
history and catalog metadata over a read-only session and proposes distribution and sort key
changes.

Redshift has no indexes, so none of ADV001–ADV008 apply

Its physical-design levers are different, and so is the blast radius. Three of the five new rules
recommend DDL that rewrites the entire table — a lock, a full disk copy, hours on a large table, and
no CONCURRENTLY escape as Postgres has. The generated script says so far more loudly than the
Postgres one does.

rule	proposes	rewrites the table?
ADV101	SORTKEY from hot range/equality predicates (zone maps skip blocks)	yes
ADV102	DISTKEY from hot join keys (avoids redistribution)	yes
ADV103	DISTSTYLE ALL for a small, frequently-joined dimension	yes
ADV104	VACUUM / ANALYZE from unsorted / stats_off	no
ADV105	surfaces Redshift Advisor's own recommendations	Advisor's DDL, attributed

ADV101/102/103 cannot reach HIGH, by construction — verified structurally (no Confidence.HIGH
literal in any of the three) and by an exhaustive sweep over every column role, cost shares including
inf/nan/negative, five stats_off/unsorted values, nine diststyles, four sortkeys and boundary
row counts. The reason is specific: Redshift exposes no per-column NDV, so distribution skew — what
makes a DISTKEY choice good or catastrophic — cannot be predicted, and a SORTKEY only repays its
rewrite if the predicate is selective, which is what NDV would measure. Claiming HIGH would assert
something about data distribution the tool cannot see, while recommending a full table rewrite. ADV104
is the exception and may reach HIGH, because it doesn't rewrite and its inputs are direct measurements.

ADV105 stays the engine's opinion, never ours. It is the only signal in this adapter that comes
from the cluster rather than our inference, so its provenance is its entire value: attributed in the
title, rationale, evidence and in the DDL file itself, never merged into one of our proposals. Where
Advisor and one of our rules agree, the report says so — that agreement is the strongest evidence this
adapter can produce.

What is verified, and what is not

This is the honest core of the PR, and it is stated prominently in the README's advise section rather
than a footnote.

Verified: the connection path runs live against postgres:16, because Redshift speaks the
PostgreSQL wire protocol — the read-only session (proven read-only in fact: a CREATE TABLE through
the adapter's own querier is refused), the clamped statement timeout, credential scrubbing including a
percent-encoded DSN password, and per-capability degradation. Every statement is syntax-checked with
sqlglot's redshift dialect and proven bindable against a real server.

Not verified: the column names and proposal semantics come from AWS documentation and have never
been executed against a live Redshift cluster. advise --engine redshift --dry-run prints every
statement for a user to run by hand, and the README invites exactly that — the first user with a
cluster is part of the verification loop, not a consumer of a finished feature.

The bindability check is worth describing, because the obvious version of it doesn't work. Running each
statement and accepting "relation does not exist" discriminates nothing: Postgres resolves table
references before parameter types, so a missing relation always masks a parameter bug — reintroducing
a real one still produced only UndefinedTable. The tests instead create same-shaped stand-in tables so
the analyzer resolves every parameter, at which point a bindable statement succeeds outright and an
unbindable one still fails. Those stand-ins also pin the adapter's column-shape assumptions in
executable form.

Bugs found along the way

• Every default run was broken. (%s IS NULL OR start_time >= %s) fails on the wire when both
  binds are NULL — i.e. any run without --since. _run swallowed it, so the run reported a zero-query
  workload reading as "healthy cluster, no traffic". Found by executing the statement rather than
  reading it.
• elapsed_time is microseconds, not milliseconds — a silent 1000× error in every cost figure and
  therefore every cost_share.
• ADV102 and ADV103 both fired for a small hot-join dimension, recommending ALTER DISTKEY and
  ALTER DISTSTYLE ALL on one table: two conflicting hours-long rewrites where following both means
  doing one and undoing it. DISTSTYLE ALL subsumes a DISTKEY choice, so ADV102 is now withheld with
  its reason folded into the survivor.
• Select-list column order was unverified in all four statements. Swapping unsorted and
  stats_off — same type, so nothing complained — inverts ADV104 and yields the wrong remediation at
  HIGH for every table. Now pinned by column name, not count.
• A dbt seam that had never been exercised. Batch 3a's enrichment turned out to already cover
  Redshift's ALTER TABLE statements through a generic fallback — but testing that branch for the first
  time revealed it clobbered a proposal's existing note, destroying ADV105's Advisor attribution.

Honest limitations, all documented

• Column names and semantics unverified against a real cluster (above).
• Without SYSLOG ACCESS UNRESTRICTED, sys_query_history silently shows only the connecting user's
  own queries — the workload looks small rather than denied, and there is no error to notice.
• --limit truncates executions, not query groups, because sys_query_history is per-execution
  where pg_stat_statements is pre-aggregated.
• Identifier case and comments split one statement into several fingerprints, inflating the group count
  and shrinking every cost_share.
• svv_table_info absence cannot distinguish a Spectrum table (which can carry none of these) from an
  empty local one, so those relations are declined — and the count is now disclosed rather than
  vanishing silently.

Verification

• 927 passed, 23 deselected — zero skips, no extras, no Docker
• 23 passed integration against live postgres:16
• main's 725 tests pass against this branch's src/ — no Postgres or dbt regression
• ruff check, ruff format --check, mypy src/sqlquality clean

Follow-ups, not in this PR

• _classify's DROP INDEX branch has the same terminal-invisibility shape as the one fixed here and
  is reachable on Postgres; counting it would change Postgres stderr, so it is left for a separate
  branch.
• CI still runs no integration tests (no Postgres service in ci.yml).
• Snowflake remains deferred pending an account to verify against.

🤖 Generated with Claude Code