perf(postgres): render compared views in one transaction per connection - #259

Deciding whether a changed view is the same one rendered differently costs a fixed number of round trips again, not four per rendering.

Why. Each rendering was its own begin, create temporary view, read back and roll back. Across major versions the target renders two per view, so 200 views took about 1,600 round trips to the target: negligible locally, but over a 50 ms link a diff went from about 48 s to about 92 s.

Now. dropEquivalent first collects every view body it will need, per connection: the source's own, the target's own, and the source's on the target across versions. It renders them in one transaction: a single DO block creates each temporary view under its own exception handler, so a body that can't be built only loses its own rendering, and the renderings go to a temporary table read back once. Everything is rolled back. Cached views skip the per-rendering transaction entirely. Other kinds (checks, indexes, policies, …) are unchanged, and anything the batch can't do falls back to the old one-by-one path.

Tests

• ViewRenderingRoundTripsPostgresTest: 25 changed views, half equivalent and half genuinely different, plus one that can't be built. The verdicts are as before, and the target sees fewer than 5 rolled-back transactions (master: 26). Skipped on PostgreSQL 14, which lacks pg_stat_force_next_flush().
• CrossVersionPostgresTest, ExpressionEquivalencePostgresTest, BulkSchemaPostgresTest and ViewGrantsRoundTripPostgresTest pass between PostgreSQL 16 and 15: 51 tests.

🤖 Generated with Claude Code