Bulk Insert PostgreSQL Go: Production-Muster

Warum Bulk Loading in PostgreSQL mehr ist als nur Durchsatz

Die erste Frage zu jedem Datenladevorgang ist nicht "Wie schnell schreibt er?" sondern "Was passiert, wenn er zweimal ausgeführt wird?" In ereignisgesteuerten Architekturen, Message Queues und verteilten Verarbeitungsabläufen kann ein Stapel erneut zugestellt werden. Fehlt dem Insert-Pfad Idempotenz, korrumpiert eine zweite Zustellung die Daten. Geschwindigkeit ohne Korrektheit ist keine Produktionseigenschaft.

Doppelte Datensätze im eingehenden Datenstrom sind ein separates Problem. Selbst eine einzelne Zustellung kann Duplikate enthalten, wenn Sie aus mehreren Quellen aggregieren, Netzwerk-Retries handhaben oder Stapel aus einer mindestens-einmal-Zustellung (At-Least-Once)-Queue verarbeiten. Ein INSERT ohne jegliche Konfliktbehandlung schreibt fröhlich jedes Duplikat, und Ihre nachgelagerten Systeme müssen mit den Konsequenzen umgehen.

Das Verbindungspool-Verhalten fügt eine weitere Dimension hinzu. PostgreSQL-Sitzungsobjekte - vor allem temporäre Tabellen - sind auf eine einzelne Backend-Verbindung begrenzt. Das spielt eine Rolle, sobald pgxpool ins Spiel kommt, denn der Pool kann aufeinanderfolgende Abfragen an verschiedene Backend-Verbindungen weiterleiten. Eine auf einer Verbindung erstellte temporäre Tabelle ist auf einer anderen unsichtbar. Das ist kein Konfigurationsfehler - so funktioniert PostgreSQL auf Protokollebene. Für Teams, die web entwicklung auf PostgreSQL durchführen, ist dieses Verständnis entscheidend.

Schließlich belastet Bulk Insert den gesamten Cluster, nicht nur die Zieltabelle. WAL-Schreibverstärkung, Replikationsverzögerung, Index-Wartung, Autovacuum-Planung und Abfrageplaner-Statistiken verändern sich, wenn Sie Millionen von Zeilen einfügen. Bulk Insert als lokales SQL-Problem zu behandeln und den operativen Kontext zu ignorieren ist eine der häufigsten Ursachen für Produktionsvorfälle, die wir bei der Überprüfung bestehender Systeme sehen.

COPY, INSERT, UNNEST und Zwischentabellen: Wie wir ein Lademuster wählen

Es gibt keinen einzigen besten Ansatz für Bulk Insert in PostgreSQL aus Go. Das richtige Muster hängt von fünf Fragen ab: Benötigen Sie Idempotenz? Wie groß ist der Stapel? Gibt es einen PgBouncer vor Ihrer Datenbank? Wie komplex ist Ihre Konfliktauflösungslogik? Braucht Ihre Zwischenschicht Absturzsicherheit (Crash-Safety)? Die Antworten führen Sie zu verschiedenen Teilen der Entscheidungsmatrix.

PostgreSQL COPY Go ist die bei weitem schnellste Option. Benchmarks mit 100 Millionen Zeilen zeigen, dass COPY in 316 Sekunden abgeschlossen wird, verglichen mit 2.653 Sekunden für Stapelverarbeitung und 94.623 Sekunden für einzelzeiligen INSERT. Aber COPY hat keine native ON CONFLICT-Unterstützung. Es schreibt Daten oder scheitert - es gibt keine eingebaute Einfügen-mit-Aktualisierung (Upsert)-Semantik.

Parametrisiertes INSERT VALUES mit Stapelverarbeitung ist einfach und funktioniert gut für kleine Stapel. Die Einschränkung ist ein Wire-Level-Limit: Laut der PostgreSQL Frontend/Backend-Protokollspezifikation wird die Parameteranzahl in einer Bind-Nachricht als INT16 codiert, was das Extended Protocol auf 65.535 Parameter begrenzt. Bei 10 Spalten pro Zeile erreichen Sie die Obergrenze bei etwa 6.500 Zeilen pro Statement. Bei 20 Spalten sinkt das auf etwa 3.200 Zeilen. Dies ist ein kritischer Punkt, den auch professionelle webdesign agentur-Teams berücksichtigen müssen.

Warum wir das nicht als "COPY vs. INSERT" formulieren

Bulk Insert als binäre Wahl zwischen COPY und INSERT zu rahmen, verfehlt die eigentliche Frage. Das Zwischentabellen-Muster - COPY in eine temporäre Tabelle, dann ein SQL-Schritt mit Konfliktauflösung - kombiniert die Geschwindigkeit von COPY im ersten Schritt mit voller Konflikt-Strategie-Kontrolle im zweiten. Es öffnet die Zwischenschicht auch für Normalisierung, Deduplizierung innerhalb des Stapels, Validierung und Anreicherung, bevor Daten die Zieltabelle überhaupt berühren. Das ist der Ansatz, den wir standardmäßig für Datenladekonveyore verwenden, die sowohl Performance als auch operative Korrektheit benötigen.

Warum das Zwischentabellen-Muster Ihnen sowohl Geschwindigkeit als auch Konflikt-Kontrolle gibt

Das Zwischentabellen-Muster funktioniert in drei Schritten: Bulk Load von Daten in eine temporäre Tabelle mit COPY, Anwendung der Konfliktauflösung mit INSERT ... ON CONFLICT oder MERGE, dann lässt sich die temporäre Tabelle selbst bereinigen. Jeder Schritt hat eine klare Verantwortung, und diese Trennung ist die Quelle der produktionsreifen Natur des Musters. Dies ist ein Muster, das sich bei der Umsetzung von online marketing-Systemen bewährt hat.

Der erste Schritt profitiert von der vollen Geschwindigkeit von COPY - keine Index-Wartung auf der Zwischentabelle, keine Constraint-Prüfungen, keine Konfliktauswertung. Der zweite Schritt operiert auf einem stabilen Snapshot des eingehenden Stapels mit normaler SQL-Semantik. Sie können innerhalb des Stapels deduplizieren, bevor er die Zieltabelle erreicht, bedingte Updates anwenden, MATCHED- und NOT MATCHED-Fälle unabhängig behandeln oder Datensätze mit Datenbankabfragen anreichern. Und weil INSERT ... ON CONFLICT atomare Einfügen-mit-Aktualisierung-Semantik bietet, ist der gesamte Datenladekonveyor sicher zum Wiederholen. Dies ist fundamental für hochperformante google seo-Systeme.

Code-Muster: COPY in Zwischentabelle mit INSERT ON CONFLICT via pgx

pgx implementiert COPY über pgx.Conn.CopyFrom() oder über pgxpool.Conn.CopyFrom() nach einem expliziten Acquire()-Aufruf. pgx CopyFrom ist die empfohlene Methode für den direkten COPY-Zugriff aus Go. Eines sollten Sie prüfen, bevor Sie CopyFrom mit Enum-Spalten verwenden: pgx verwendet ausschließlich das binäre Wire-Format für COPY, was zu Typfehler-Fehlern führen kann, wenn Enums auf der Go-Seite nicht korrekt behandelt werden.

// Acquire a dedicated connection from the pool
conn, err := pool.Acquire(ctx)
if err != nil {
    return err
}
defer conn.Release()

tx, err := conn.Begin(ctx)
if err != nil {
    return err
}
defer tx.Rollback(ctx)

// Create temp table without copying indexes from target
_, err = tx.Exec(ctx, `
    CREATE TEMP TABLE staging_events (
        id         BIGINT,
        user_id    BIGINT,
        event_type TEXT,
        created_at TIMESTAMPTZ
    ) ON COMMIT DROP
`)
if err != nil {
    return err
}

// Bulk load via COPY
rows := make([][]interface{}, len(batch))
for i, e := range batch {
    rows[i] = []interface{}{e.ID, e.UserID, e.EventType, e.CreatedAt}
}

_, err = conn.Conn().CopyFrom(
    ctx,
    pgx.Identifier{"staging_events"},
    []string{"id", "user_id", "event_type", "created_at"},
    pgx.CopyFromRows(rows),
)
if err != nil {
    return err
}

// Conflict resolution step
_, err = tx.Exec(ctx, `
    INSERT INTO events (id, user_id, event_type, created_at)
    SELECT id, user_id, event_type, created_at FROM staging_events
    ON CONFLICT (id) DO NOTHING
`)
if err != nil {
    return err
}

return tx.Commit(ctx)

Die ON COMMIT DROP-Klausel stellt sicher, dass die Zwischentabelle beim Commit oder Rollback der Transaktion vernichtet wird. Keine Sitzungsverschmutzung, kein Catalog-Bloat durch angesammelte temporäre Tabellen über Pool-Verbindungen hinweg.

MERGE für komplexe Konflikt-Strategie (PostgreSQL 15+)

Wenn ON CONFLICT nicht ausdrucksstark genug ist - zum Beispiel wenn Sie je nach Alter eines vorhandenen Datensatzes im Vergleich zum eingehenden unterschiedliche Update-Logik benötigen - bietet MERGE einen einzelnen atomaren Operator, der INSERT, UPDATE und DELETE in einem Durchgang verarbeiten kann. Er erschien in PostgreSQL 15 (veröffentlicht Oktober 2022) und ist das richtige Werkzeug, wenn Zwischentabelle + ON CONFLICT mehrere bedingte Statements erfordern würde.

MERGE INTO events t
USING staging_events s ON (t.id = s.id)
WHEN MATCHED AND s.updated_at > t.updated_at THEN
  UPDATE SET
    event_type = s.event_type,
    updated_at = s.updated_at
WHEN NOT MATCHED THEN
  INSERT (id, user_id, event_type, updated_at)
  VALUES (s.id, s.user_id, s.event_type, s.updated_at);

Laut der PostgreSQL MERGE-Dokumentation unterstützt MERGE auch eine WHEN MATCHED THEN DELETE-Klausel, was es zu einer praktischen Option für vollständige Synchronisierungs-Datenladekonveyore macht, die Datensätze entfernen müssen, die in der Quelle nicht mehr vorhanden sind.

Was in Go schiefläuft, wenn Sie Sitzungsbereich und Verbindungspools vergessen

Temporäre Tabellen in PostgreSQL sind im Sitzungsbereich gültige Objekte (temporäre Tabelle im Kontext von Hochlast-Datenbank-Systemen ein häufig unterschätztes Thema). Sie existieren für die Lebensdauer der Backend-Verbindung, die sie erstellt hat, und sind für alle anderen Verbindungen unsichtbar. Wenn Ihre Anwendung pgxpool verwendet, kann jeder Aufruf von pool.Exec() oder pool.Query() auf einer anderen Backend-Verbindung landen. Wenn Sie eine temporäre Tabelle in einem Aufruf erstellen und versuchen, sie im nächsten zu verwenden, erhalten Sie einen "relation does not exist"-Fehler - nicht weil die Tabelle gelöscht wurde, sondern weil die zweite Abfrage zu einer anderen Verbindung ging, die sie nie gesehen hat.

Es gibt zwei korrekte Muster für die Verwaltung in Go. Das erste ist pool.Begin(ctx): Eine Transaktion hält eine einzelne Verbindung von der Akquisition bis zum Commit oder Rollback, sodass alle Operationen innerhalb der Transaktion denselben Sitzungszustand sehen. Das zweite ist pool.Acquire(ctx) mit explizitem conn.Release(), wenn Sie fertig sind: Das ist nützlich, wenn Sie mehrere Operationen über separate Transaktionen auf derselben Verbindung ausführen möchten.

Das ON COMMIT DROP-Muster

CREATE TEMP TABLE ... ON COMMIT DROP innerhalb einer Transaktion zu verwenden ist der sauberste Weg, Zwischentabellen in einer gepoolten Umgebung zu handhaben. Die Tabelle wird innerhalb einer einzelnen Transaktion erstellt und vernichtet, sodass kein Risiko von Namenskollisionen bei gleichzeitigen Datenladeaufrufen besteht und keine residuellen temporären Tabellen-Einträge im System-Catalog angesammelt werden. Für schreibintensive Datenladekonveyore ist Catalog-Bloat durch ungereinigte temporäre Tabellen ein reales operatives Problem, das dieses Muster vollständig eliminiert.

PgBouncer und Anweisungszwischenspeicher in pgx

pgx speichert vorbereitete Anweisungen standardmäßig über seinen Anweisungszwischenspeicher-Mechanismus. Im Transaction-Pooling-Modus machte PgBouncer das historisch inkompatibel: Anweisungen, die auf einer Verbindung vorbereitet wurden, sind nicht verfügbar, nachdem PgBouncer Sie einer anderen Backend-Verbindung zugewiesen hat. Vor PgBouncer 1.21 erforderte die Verwendung von pgx mit PgBouncer im Transaction-Modus die vollständige Deaktivierung des Anweisungszwischenspeichers.

PgBouncer 1.21 führte protokollbasiertes Prepared-Statement-Tracking über max_prepared_statements ein, aber wie die Analyse von Crunchy Data erklärt, können manuelle DEALLOCATE-Aufrufe das Schema immer noch brechen. Die sicherste Konfiguration für pgx hinter jeder Version von PgBouncer im Transaction-Modus bleibt:

conn, err := pgx.Connect(ctx, connString)
// or via pgxpool config:
config.ConnConfig.DefaultQueryExecMode = pgx.QueryExecModeSimpleProtocol

Das Simple Protocol deaktiviert den Anweisungszwischenspeicher und sendet Abfragen als Klartext, was mit jeder PgBouncer-Konfiguration funktioniert. Der Performance-Kompromiss ist Abfrageplanung bei jeder Ausführung - evaluieren Sie das gegen Ihre tatsächlichen Abfragemuster, bevor Sie es global anwenden.

Warum LIKE INCLUDING ALL ein schlechter Standard für Zwischentabellen ist

CREATE TEMP TABLE staging LIKE target INCLUDING ALL ist eine verbreitete Abkürzung, die die vollständige Struktur der Zieltabelle in die Zwischenschicht kopiert - einschließlich aller Indizes, CHECK-Constraints, Fremdschlüssel-Constraints und Statistiken. Für eine Zwischentabelle, die nur dazu dient, Daten während eines Bulk-Ladevorgangs zu halten, ist das der falsche Kompromiss. COPY pflegt jeden Index beim Schreiben jeder Zeile, was den größten Teil des Geschwindigkeitsvorteils eliminiert, der COPY überhaupt attraktiv gemacht hat.

Index-Wartung während des Bulk-Ladevorgangs ist O(N * Anzahl_der_Indizes). Wenn Ihre Zieltabelle fünf Indizes hat und Sie eine Million Zeilen einfügen, zahlt COPY in eine Zwischentabelle mit LIKE INCLUDING ALL die Index-Update-Kosten für jeden dieser fünf Indizes auf jeder Zeile. Eine Zwischentabelle ohne Indizes schreibt saubere, schnelle Datenseiten und nichts anderes.

Wann spezifische Optionen einzubinden sind

Es gibt legitime Fälle für selektive Einbindung. INCLUDING DEFAULTS ist nützlich, wenn die Zwischentabelle Standard-Spaltenwerte von der Zieltabelle erben muss. INCLUDING GENERATED ist wichtig, wenn Sie mit generierten Spalten arbeiten, die während der Zwischen-zu-Ziel-Übertragung berechnet werden sollen. Indizes in der Zwischentabelle sind nur dann zu erstellen, wenn Sie Zeilen innerhalb des Stapels vor dem Konfliktauflösungsschritt deduplizieren müssen - und selbst dann nur den Index erstellen, der diese spezifische Deduplizierungs-Abfrage unterstützt.

Die praktische Regel: Schreiben Sie Ihr Zwischentabellen-DDL explizit aus, nur mit den Spalten und Constraints, die Sie tatsächlich benötigen. Das kostet ein paar Zeilen Code mehr und bewahrt Sie vor einer schwer zu debuggenden Performance-Regression, wenn sich die Tabellenstruktur weiterentwickelt.

Wo der eigentliche Engpass liegt: Indizes, Fremdschlüssel, WAL, ANALYZE und Autovacuum

Die meisten Bulk-Insert-Performance-Probleme liegen nicht im SQL-Statement selbst. Sie liegen in der operativen Umgebung drum herum. Datenbankindizes, Fremdschlüssel, WAL-Druck, veraltete Planer-Statistiken und Autovacuum-Planung bestimmen zusammen den tatsächlichen Durchsatz Ihres Datenladekonveyors - und sie sind das erste, was wir überprüfen, wenn wir ein System mit Bulk-Insert-Performance-Problemen untersuchen.

Datenbankindizes sind der direkteste Faktor. Jede in eine Tabelle eingefügte Zeile aktualisiert alle Indizes dieser Tabelle. Für Bulk Insert in eine bestehende Tabelle mit mehreren Indizes ist das eine O(N * Index-Anzahl)-Operation. Die PostgreSQL-Dokumentation zum Befüllen einer Datenbank empfiehlt ausdrücklich, Daten in Tabellen ohne Indizes zu laden und Indizes danach hinzuzufügen, wenn in leere Tabellen geladen wird. Für Live-Tabellen erzielt das Zwischentabellen-Muster denselben Effekt: Die Zwischentabelle hat keine Indizes, sodass COPY schnell läuft, und Index-Updates passieren nur während des INSERT-Schritts auf der Zieltabelle.

Fremdschlüssel fügen referenzielle Integritätsprüfungen bei jeder eingefügten Zeile hinzu. Das temporäre Deaktivieren von FK-Constraint-Triggern via ALTER TABLE DISABLE TRIGGER ALL ist eine bekannte Technik für große Bulk Loads, erfordert aber sorgfältiges Wiederaktivieren und ein anschließendes ANALYZE. Verwenden Sie das nur, wenn die Datenkorrektheit-Garantie anderswo im Datenladekonveyor bereitgestellt wird.

WAL-Druck betrifft den gesamten Cluster. Große Bulk Inserts erzeugen erheblichen WAL-Traffic (WAL-Replikation eingeschlossen), was die Prüfpunkt-Häufigkeit erhöht und I/O-Spitzen erzeugt. Das Erhöhen von max_wal_size erlaubt PostgreSQL, Prüfpunkte länger hinauszuzögern und das I/O-Muster zu glätten. Das Erhöhen von maintenance_work_mem beschleunigt die Index-Erstellung oder FK-Neuerstellung, die einem Bulk Load folgt.

ANALYZE und Autovacuum nach der Aufnahme

Nach einem großen Bulk Insert sind die Abfrageplaner-Statistiken für die Zieltabelle veraltet. Pläne, die vor dem Load optimal waren, können auf den neu befüllten Daten völlig falsch sein. Das explizite Ausführen von ANALYZE nach Bulk Insert stellt sicher, dass Planer genaue Zeilenanzahl- und Verteilungsschätzungen sehen. Für automatisierte Datenladekonveyore lohnt es sich, das als Standard-Post-Load-Schritt hinzuzufügen.

Autovacuum-Planung ist ein subtileres Anliegen. Bulk Insert erstellt viele aktive Datensätze, und Autovacuum läuft nicht sofort nach einer schreibintensiven Operation. Der Rückstand manifestiert sich später: Die nächste Runde von UPDATE- oder DELETE-Operationen auf dieser Tabelle erzeugt ungültige Datensätze, und Autovacuum kann möglicherweise nicht mithalten, wenn es nicht für schreibintensive Tabellen abgestimmt wurde. Das Überwachen von pg_stat_user_tables.n_dead_tup und das Anpassen von autovacuum_vacuum_scale_factor für schreibintensive Tabellen ist Teil der operativen Arbeit, die ein ausgereifter Datenladekonveyor erfordert.

Wann UNNEST, MERGE, UNLOGGED-Tabellen und Partitionierung wirklich sinnvoll sind

UNNEST ist der praktische Mittelweg für Stapelgrößen zwischen tausend und fünfzigtausend Zeilen. Anstatt N*M Parameter (Zeilen * Spalten) nimmt UNNEST einen Array-Parameter pro Spalte unabhängig davon, wie viele Zeilen im Stapel sind. Der Abfragetext bleibt über alle Stapelgrößen hinweg konstant, was das Zwischenspeichern vorbereiteter Anweisungen effektiv macht und die PgBouncer-Kompatibilität unkompliziert. Benchmarks zeigen, dass UNNEST 100 Millionen Zeilen in 533 Sekunden verarbeitet - langsamer als COPYs 316 Sekunden, aber mit voller ON CONFLICT-Unterstützung und ohne Zwischentabellen-Overhead.

ids := make([]int64, len(batch))
userIDs := make([]int64, len(batch))
types := make([]string, len(batch))
timestamps := make([]time.Time, len(batch))

for i, e := range batch {
    ids[i] = e.ID
    userIDs[i] = e.UserID
    types[i] = e.EventType
    timestamps[i] = e.CreatedAt
}

_, err = pool.Exec(ctx, `
    INSERT INTO events (id, user_id, event_type, created_at)
    SELECT * FROM unnest($1::bigint[], $2::bigint[], $3::text[], $4::timestamptz[])
        AS t(id, user_id, event_type, created_at)
    ON CONFLICT (id) DO NOTHING
`, ids, userIDs, types, timestamps)

Die Einschränkung von UNNEST ist der Speicher: Das gesamte Stapel-Array wird in Go materialisiert, bevor die Abfrage gesendet wird. Bei sehr großen Stapelgrößen (100k+ Zeilen) wird das Zwischentabellen-plus-COPY-Muster schneller und speichereffizienter sein. Der richtige Schwellenwert hängt von Ihrer Zeilenbreite und dem verfügbaren Arbeitsspeicher-Heap ab, aber wir wechseln generell bei etwa 50k Zeilen zur Zwischentabellen-Variante.

UNLOGGED-Tabellen für Zwischenspeicherung

UNLOGGED-Tabellen überspringen WAL-Schreibvorgänge vollständig, was sie für Zwischendaten deutlich schneller macht. Laut der PostgreSQL CREATE TABLE-Dokumentation fehlt UNLOGGED-Tabellen die Absturzsicherheit (Daten gehen bei unsauberem Herunterfahren verloren) und sie werden nicht auf Standby-Server repliziert. Für eine Zwischentabelle, die Daten nur für die Dauer eines Bulk-Ladevorgangs hält, sind diese Kompromisse akzeptabel. Für alles, das einen Datenbank-Neustart überleben oder auf einem Read-Replica erscheinen muss, verwenden Sie stattdessen eine normale temporäre Tabelle.

Partitionierung in Datenladekonveyoren

Tabellenpartitionierung hilft Datenladekonveyoren auf eine Weise, die über Query-Performance hinausgeht. Das Laden von Daten in eine bestimmte Partition erlaubt PostgreSQL, Constraint-Prüfungen und Index-Wartung auf nicht zusammenhängenden Partitionen zu überspringen. Die Verwaltung des Datenlebenszyklus durch Partitions-Level-Operationen - Anhängen einer neuen Partition, Trennen und Löschen einer alten - ist dramatisch schneller als DELETE auf einer riesigen Tabelle auszuführen. Wie die PostgreSQL-Partitionierungs-Dokumentation anmerkt, ist ANALYZE auf einzelnen Partitionen auch schneller als ANALYZE auf einer monolithischen Tabelle, was für hochfrequente Datenladekonveyore wichtig ist, bei denen die Frische der Statistiken operativ wichtig ist.

Code-Muster, die wir für B2B-Hochlast-Projekte empfehlen

Die drei Produktionsmuster, die wir verwenden, decken die meisten Ladeszenarien ab. Alle drei teilen eine Anforderung: explizites Verbindungsmanagement. Sie können Bulk Insert nicht korrekt über die Convenience-Methoden von pgxpool allein durchführen, wenn temporäre Tabellen oder COPY im Spiel sind. Für Unternehmen, die hochperformante Systeme benötigen, ist das Verständnis dieser Muster - ähnlich wie bei professionellen Geo-SEO Strategien - ein entscheidender Wettbewerbsvorteil.

Muster 1: CopyFrom mit explizitem Acquire

Verwenden Sie das für reinen Bulk Load ohne Konfliktbehandlung. Es bietet maximalen Schreibdurchsatz mit minimaler Code-Komplexität.

func bulkInsert(ctx context.Context, pool *pgxpool.Pool, rows []EventRow) error {
    conn, err := pool.Acquire(ctx)
    if err != nil {
        return fmt.Errorf("acquire connection: %w", err)
    }
    defer conn.Release()

    _, err = conn.Conn().CopyFrom(
        ctx,
        pgx.Identifier{"events"},
        []string{"id", "user_id", "event_type", "created_at"},
        pgx.CopyFromSlice(len(rows), func(i int) ([]interface{}, error) {
            r := rows[i]
            return []interface{}{r.ID, r.UserID, r.EventType, r.CreatedAt}, nil
        }),
    )
    return err
}

Muster 2: Zwischentabelle via Transaktion mit ON COMMIT DROP

Verwenden Sie das, wenn Sie Einfügen-mit-Aktualisierung-Semantik, Deduplizierung oder eine beliebige Konfliktauflösung benötigen. Die Transaktion garantiert Verbindungsaffinität für alle drei Schritte (Erstellen, Laden, Zusammenführen), und ON COMMIT DROP hält den Lebenszyklus der temporären Tabelle eng begrenzt.

func upsertBatch(ctx context.Context, pool *pgxpool.Pool, rows []EventRow) error {
    tx, err := pool.Begin(ctx)
    if err != nil {
        return fmt.Errorf("begin tx: %w", err)
    }
    defer tx.Rollback(ctx)

    _, err = tx.Exec(ctx, `
        CREATE TEMP TABLE staging_events (
            id BIGINT, user_id BIGINT,
            event_type TEXT, created_at TIMESTAMPTZ
        ) ON COMMIT DROP
    `)
    if err != nil {
        return fmt.Errorf("create staging: %w", err)
    }

    // CopyFrom requires a *pgx.Conn, not a pgx.Tx
    // Extract the underlying connection via pgxpool.Tx
    ptx := tx.(*pgxpool.Tx)
    _, err = ptx.Conn().CopyFrom(
        ctx,
        pgx.Identifier{"staging_events"},
        []string{"id", "user_id", "event_type", "created_at"},
        pgx.CopyFromSlice(len(rows), func(i int) ([]interface{}, error) {
            r := rows[i]
            return []interface{}{r.ID, r.UserID, r.EventType, r.CreatedAt}, nil
        }),
    )
    if err != nil {
        return fmt.Errorf("copy: %w", err)
    }

    _, err = tx.Exec(ctx, `
        INSERT INTO events (id, user_id, event_type, created_at)
        SELECT id, user_id, event_type, created_at FROM staging_events
        ON CONFLICT (id) DO NOTHING
    `)
    if err != nil {
        return fmt.Errorf("merge: %w", err)
    }

    return tx.Commit(ctx)
}

Muster 3: UNNEST + ON CONFLICT

Verwenden Sie das für Stapel im Bereich von 1k bis 50k Zeilen, bei denen Sie die Einfachheit einer einzelnen Abfrage, Prepared-Statement-Kompatibilität und ON CONFLICT ohne den Overhead einer Zwischentabelle wünschen. Es funktioniert sauber mit PgBouncer im Transaction-Modus, wenn Simple Protocol konfiguriert ist.

func unnestUpsert(ctx context.Context, pool *pgxpool.Pool, rows []EventRow) error {
    ids := make([]int64, len(rows))
    userIDs := make([]int64, len(rows))
    types := make([]string, len(rows))
    timestamps := make([]time.Time, len(rows))

    for i, r := range rows {
        ids[i] = r.ID
        userIDs[i] = r.UserID
        types[i] = r.EventType
        timestamps[i] = r.CreatedAt
    }

    _, err := pool.Exec(ctx, `
        INSERT INTO events (id, user_id, event_type, created_at)
        SELECT * FROM unnest($1::bigint[], $2::bigint[], $3::text[], $4::timestamptz[])
            AS t(id, user_id, event_type, created_at)
        ON CONFLICT (id) DO NOTHING
    `, ids, userIDs, types, timestamps)

    return err
}

Anti-Muster, die Sie vermeiden sollten

• N einzelne INSERTs in einer Schleife: ein Anfrage-Antwort-Zyklus pro Zeile, keine Stapelverarbeitung. Selbst mit einer schnellen Verbindung ist das um Größenordnungen langsamer als jeder gestapelte Ansatz.
• CREATE TEMP TABLE außerhalb einer Transaktion durch einen Pool: nachfolgende Operationen landen auf verschiedenen Verbindungen und scheitern mit "relation does not exist".
• LIKE INCLUDING ALL für Zwischentabellen: importiert alle Indizes und Constraints von der Zieltabelle und macht COPY zu einer langsamen indizierten Schreiboperation.
• Das 65.535-Parameter-Limit ignorieren: Wenn Stapelgröße oder Spaltenanzahl wächst, trifft parametrisiertes INSERT VALUES stillschweigend die Protokoll-Obergrenze und gibt einen Fehler zurück.

Den richtigen Bulk-Load-Pfad für Ihr System wählen

Das korrekte Lademuster für ein Hochlastsystem wird nicht durch einen synthetischen Benchmark bestimmt, sondern durch Ihre operativen Constraints. Arbeiten Sie die Entscheidungspunkte der Reihe nach durch: Benötigen Sie Idempotenz? Enthält Ihr Stack PgBouncer? Was sind Ihre Konflikt-Semantiken? Was sind Ihre Absturzsicherheits- und Replikationsanforderungen für Zwischendaten? Die Antworten engen die Optionen auf ein oder zwei Muster ein, und die Wahl zwischen ihnen wird unkompliziert.

Bevor Sie einen Datenladekonveyor in die Produktion bereitstellen, arbeiten Sie diese Prüfliste durch:

• Temporäre Tabellen-Operationen befinden sich innerhalb einer Transaktion oder verwenden explizites Acquire/Release
• Zwischentabellen-DDL spezifiziert nur erforderliche Spalten, kein LIKE INCLUDING ALL
• UNNEST-Stapelgröße bleibt unter 50k Zeilen, oder Zwischentabelle + COPY wird stattdessen verwendet
• pgx ist für Simple Protocol konfiguriert, wenn PgBouncer im Stack ist
• ANALYZE wird nach großen Stapel-Inserts als Post-Load-Schritt aufgerufen
• Autovacuum-Einstellungen für schreibintensive Tabellen sind überprüft und abgestimmt
• max_wal_size und maintenance_work_mem sind für Bulk-Workloads angemessen gesetzt
• Konfliktauflösung ist idempotent - der Datenladekonveyor kann sicher wiederholt werden

Die operative Seite - WAL-Verzögerung, Autovacuum-Rückstand, Replikationsverzögerung, Planer-Statistik-Drift - erfordert dieselbe Design-Aufmerksamkeit wie der Schreibpfad selbst. Systeme, die die Aufnahme in der Entwicklung gut handhaben, degradieren in der Produktion oft, weil operatives Monitoring und Optimierung übersprungen wurden. Das Überwachen von pg_stat_replication für Verzögerung, pg_stat_user_tables für ungültige-Datensätze-Ansammlung und pg_stat_progress_copy während aktiver Loads gibt Ihnen frühzeitige Sichtbarkeit in die Probleme, die typischerweise Wochen nach der Bereitstellung eines Systems auftauchen.

Wenn Sie ein Hochlast-Backend-System aufbauen oder überprüfen und einen Engineering-Partner benötigen, der diese Art von Produktionskomplexität versteht - von der Datenladekonveyor-Architektur bis hin zu langfristigen PostgreSQL-Operationen - ist das Webdelo-Team offen dafür, Ihr Projekt zu besprechen. Wir arbeiten mit B2B-Unternehmen zusammen, die zuverlässige, wartbare Systeme brauchen, nicht nur Code, der schnell ausgeliefert wird. Melden Sie sich, wenn Sie Ihr Datenladekonveyor-Design besprechen oder eine technische Überprüfung Ihres aktuellen Ansatzes erhalten möchten.