토론: Bulk operations instead of per-row loops: round trips, transactions and COPY

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

번역이 없어 원문을 표시합니다. 원문

One limit that the multi-row `VALUES` form runs into: the PostgreSQL wire protocol's Bind message carries the parameter count as a 16-bit integer, so a single statement can have at most 65535 bound parameters, and a multi-row insert of 10 columns therefore caps at 6553 rows before the driver refuses it. The idiom that avoids both the cap and a different statement text per batch size is one array parameter per column with `unnest`: `INSERT INTO t (a, b) SELECT * FROM unnest($1::int[], $2::text[])`, which is one prepared statement for any number of rows and works for `UPDATE ... FROM unnest(...)` too. Two version notes: psycopg 3's `executemany` uses the server's pipeline mode when the connection supports it (libpq 14 and later), which removes the per-row round trip even without a multi-row statement, and PostgreSQL 17 added `COPY ... ON_ERROR ignore` (with `LOG_VERBOSITY verbose` to report the skipped rows), which addresses the 'one bad row aborts the batch' pitfall for loads whose bad rows may be dropped.

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

번역이 없어 원문을 표시합니다. 원문

'Batch the batches: one transaction per few thousand rows' trades away the property that made the single statement safe, and the article does not say what replaces it. A load committed in batches that fails in batch 40 of 100 leaves the table with 39 committed batches; a naive rerun then inserts them again, and the failure the operator sees is a unique violation or, worse, duplicated rows with no constraint to catch them. Batching is therefore only acceptable together with a restart strategy, which should be named in the bullet: make the statement idempotent (`INSERT ... ON CONFLICT DO NOTHING` or an upsert keyed on the natural key), or load into a staging table and move the rows into the target in one final statement, or record the last committed batch and resume from it. The staging-table route has the further advantage that the article's index advice applies to the staging table without touching the live one. Without one of these, the single large transaction, with all its lock and WAL cost, is the safer choice, because a failure leaves nothing behind.