Hvordan bulk-loader du data effektivt med COPY?

Question

Accepted Answer

**`COPY`** er PostgreSQLs højtperformant kommando til **bulk loading og eksport** af data — flytning af store mængder data mellem en fil (eller stream) og en tabel meget hurtigere end individuelle `INSERT`-statements. Det er standardværktøjet til import/eksport af store datasæt.

## COPY til hurtig bulk loading

```sql
-- load data from a CSV file into a table (server-side; needs file access + privileges)
COPY users (name, email, age) FROM '/path/data.csv' WITH (FORMAT csv, HEADER true);

-- export a table to a CSV file
COPY users TO '/path/export.csv' WITH (FORMAT csv, HEADER true);

-- from psql (client-side — works without server file access): use \copy
\copy users FROM 'data.csv' WITH (FORMAT csv, HEADER true)
```

`COPY` læser/skriver en helt fil i én operation — dramatisk hurtigere end at køre tusindvis af individuelle INSERTs.

## Hvorfor COPY er så meget hurtigere end INSERT

```text
❌ thousands of individual INSERTs:
   each is a separate statement → per-statement overhead, possibly per-row transactions,
   network round-trips → SLOW for large data (can be 10-100x slower)

✅ COPY:
   one bulk operation, minimal overhead, optimized data path → FAST
→ For loading large datasets, COPY is the go-to; INSERTs are for small/individual rows.
```

## COPY vs \copy (server-side vs client-side)

```text
COPY (SQL command) → reads/writes files on the SERVER, needs superuser/file privileges
\copy (psql command) → reads/writes files on the CLIENT, no special privileges
→ Use \copy when running from your machine against a remote database.
```

## Tips til bulk loading af store datasæt

```text
✓ Use COPY (not INSERTs) for large data
✓ Consider dropping/disabling indexes and constraints during a huge load, then
  recreating them after (building an index once is faster than maintaining it per-row)
✓ Load within a single transaction; increase maintenance_work_mem for index rebuilds
✓ For programmatic bulk inserts, use multi-row INSERT or the driver's COPY support
```

## Hvorfor det betyder noget

`COPY` er det væsentlige PostgreSQL-værktøj til **effektiv bulk data loading og eksport**, og forståelse af det er værdifuldt for ethvert scenarie, der involverer store datasæt — datamigrering, ETL, import/eksport, seeding og analyser, som er almindelige behov i den virkelige verden.

Hovedværdien er **performance**: loading af store mængder data med individuelle `INSERT`-statements er dramatisk langsommere (per-statement overhead, round-trips — potentielt 10-100 gange langsommere), mens `COPY` udfører loadingen som én optimeret bulk operation, hvilket gør det til førstevalget for import eller eksport af store datasæt (tusindvis til millioner af rækker).

Forståelse af *hvorfor* COPY er så meget hurtigere (bulk operation vs per-row overhead) præciserer hvornår man skal bruge det (store data) versus INSERTs (små/individuelle rækker).

Kendskab til den praktiske forskel mellem **`COPY`** (server-side SQL kommando, kræver fil adgang/rettigheder) og **`\copy`** (psql client-side kommando, ingen særlige rettigheder — fungerer mod fjerne databaser fra din maskine) er vigtig for faktisk at bruge det i forskellige kontekster.

**Bulk-loading tips** (brug COPY over INSERTs, drop/genskab indekser omkring massive loads da det er hurtigere at bygge et indeks én gang end at vedligeholde det per-row, loading i en transaktion) er værdifuld optimiseringsviden for store imports.

Da bulk data-operationer (migrering, import, eksport, ETL) er almindelige, og da COPY er standardmetoden med høj performance til at håndtere dem i PostgreSQL (langt overlegen for INSERTs med store data), er forståelse af COPY — dens performance-fordel, COPY vs \copy-distinktionen, og bulk-loading best practices — værdifuld, praktisk relevant viden til effektivt at flytte store datasæt ind og ud af Postgres, et hyppigt operationelt behov hvor brug af det rigtige værktøj (COPY) gør en stor forskel.