0Pricing
PostgreSQL Performance & Query Optimization · Lección

Aplazamiento de índices y restricciones durante la carga

Elimine y reconstruya índices y restricciones alrededor de las cargas masivas para reducir drásticamente la amplificación de escritura.

Aplazamiento de índices y restricciones durante la carga es una lección gratuita de PostgreSQL Performance & Query Optimization en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de PostgreSQL Performance & Query Optimization, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de PostgreSQL Performance & Query Optimization incluye 4 lecciones en total.

Partes de esta lección aún no han sido traducidas y se muestran en inglés.

Why Bulk Loads Get Slow

When you load millions of rows into a table that already has indexes and constraints, PostgreSQL pays a hidden tax on every single row.

  • Each index must be updated (B-tree page splits, WAL writes).
  • Each foreign key triggers a lookup against the referenced table.
  • Each unique/check constraint is validated per-row.

This per-row work is called write amplification: one logical INSERT becomes many physical writes. The core optimization in this lesson is to defer that work — load the raw data first, then build indexes and validate constraints once, in bulk.

The Per-Index Cost

Maintaining a B-tree index during a load is not free. For each inserted row, PostgreSQL must walk the tree, find the leaf page, possibly split it, and log the change to WAL.

Building the same index after the data is present is far cheaper: PostgreSQL sorts all keys at once and writes dense, sequential pages. A table with 5 indexes loaded row-by-row does roughly 6x the write work versus loading the heap alone.

The takeaway: fewer indexes present during load = less amplification.

Pattern: Drop, Load, Rebuild

The classic ETL pattern for a table that will receive a large load is:

  • Drop the secondary indexes.
  • Load the data (COPY is fastest).
  • Rebuild the indexes in one pass.

Below is the skeleton. Note we keep the primary key for now and only drop secondary indexes that are not needed during the load itself.

DROP INDEX idx_orders_customer_id;
DROP INDEX idx_orders_created_at;

COPY orders FROM '/data/orders.csv' WITH (FORMAT csv, HEADER true);

CREATE INDEX idx_orders_customer_id ON orders (customer_id);
CREATE INDEX idx_orders_created_at ON orders (created_at);

COPY Beats INSERT for Loading

Once indexes are out of the way, the loading method matters. COPY streams rows in a single command with minimal per-row overhead, while thousands of individual INSERT statements each pay parse, plan, and round-trip costs.

For ETL throughput, prefer COPY (or \copy from psql) over row-at-a-time inserts. If you must use INSERT, batch many rows per statement.

COPY staging_events (user_id, event_type, payload, created_at)
FROM '/data/events.csv'
WITH (FORMAT csv, HEADER true);

Deferring Foreign Key Validation

Foreign keys are validated per-row during a load, doing an index lookup on the parent table each time. You can avoid this by making the constraint NOT VALID first, loading, then validating in bulk.

ADD CONSTRAINT ... NOT VALID adds the FK without checking existing rows. New rows are still checked on insert, so to truly skip per-row work you drop and re-add after load, or load before adding the FK.

-- Add the FK without scanning existing rows
ALTER TABLE orders
  ADD CONSTRAINT fk_orders_customer
  FOREIGN KEY (customer_id) REFERENCES customers (id)
  NOT VALID;

-- Later, validate all rows in one bulk pass
ALTER TABLE orders VALIDATE CONSTRAINT fk_orders_customer;

Why NOT VALID Then VALIDATE Helps

Adding a foreign key the normal way takes an ACCESS EXCLUSIVE lock and scans the whole table while blocking writes. The two-step approach splits this:

  • ADD ... NOT VALID is fast and takes a brief strong lock only to record the constraint.
  • VALIDATE CONSTRAINT scans the table under a weaker SHARE UPDATE EXCLUSIVE lock, allowing concurrent reads and writes.

For loads, this means you do the expensive validation once, after all data is present, rather than per-row.

DEFERRABLE Constraints Within a Transaction

PostgreSQL also supports DEFERRABLE constraints, which postpone checking until the end of a transaction (COMMIT). This is different from dropping a constraint: the check still runs, just later.

It is useful when rows arrive in an order that temporarily violates an FK or unique constraint (for example, child rows before parents within one transaction).

ALTER TABLE order_items
  ADD CONSTRAINT fk_items_order
  FOREIGN KEY (order_id) REFERENCES orders (id)
  DEFERRABLE INITIALLY DEFERRED;

BEGIN;
  -- insert children and parents in any order;
  -- FK is checked only at COMMIT
COMMIT;

Deferred Check vs Dropped Constraint

Be clear on the trade-off:

  • DEFERRABLE INITIALLY DEFERRED still validates every row, just at COMMIT instead of at INSERT. It fixes ordering problems but does not remove the validation cost.
  • Drop / re-add (or NOT VALID + VALIDATE) removes per-row work entirely and revalidates in one efficient scan.

For maximum throughput on huge loads, dropping and rebuilding wins. For correctness with tricky insert ordering, deferrable is the right tool.

Tuning the Index Rebuild

Rebuilding indexes after a load is itself a sort-heavy operation. Two settings make it much faster for the session running the load:

  • maintenance_work_mem — more memory means fewer external sort merges when building indexes.
  • max_parallel_maintenance_workers — lets a single CREATE INDEX use multiple CPUs.

Raise these for the load session, then build the indexes.

SET maintenance_work_mem = '2GB';
SET max_parallel_maintenance_workers = 4;

CREATE INDEX idx_orders_customer_id ON orders (customer_id);
CREATE INDEX idx_orders_created_at ON orders (created_at);

A Complete ETL Sequence

Putting it together for a large incremental load into an existing table, a robust order of operations is:

  • Drop secondary indexes.
  • Drop or disable expensive foreign keys.
  • Raise maintenance_work_mem.
  • Load via COPY.
  • Rebuild indexes.
  • Re-add FKs and VALIDATE.
  • Run ANALYZE so the planner has fresh statistics.
ALTER TABLE orders DROP CONSTRAINT fk_orders_customer;
DROP INDEX idx_orders_created_at;

SET maintenance_work_mem = '1GB';
COPY orders FROM '/data/orders.csv' WITH (FORMAT csv, HEADER true);

CREATE INDEX idx_orders_created_at ON orders (created_at);
ALTER TABLE orders
  ADD CONSTRAINT fk_orders_customer
  FOREIGN KEY (customer_id) REFERENCES customers (id);

ANALYZE orders;

Don't Forget ANALYZE

After a big load, the table statistics the planner relies on are stale — it may still think the table is tiny. That leads to bad plans (sequential scans where an index would win, or wrong join orders).

Always run ANALYZE (or VACUUM ANALYZE) on freshly loaded tables before running queries against them. Rebuilding indexes does not update planner statistics; only ANALYZE does.

ANALYZE orders;
-- or to also reclaim space and freeze:
VACUUM ANALYZE orders;

Quick Check

Test your understanding of the throughput trade-offs.

Recap

Key takeaways for deferring indexes and constraints during bulk loads:

  • Live indexes and constraints cause write amplification — one INSERT becomes many physical writes.
  • The winning pattern is drop, load, rebuild: remove secondary indexes and FKs, load with COPY, then recreate them in one pass.
  • ADD CONSTRAINT ... NOT VALID followed by VALIDATE CONSTRAINT moves FK checking out of the per-row path and into a single bulk scan under a lighter lock.
  • DEFERRABLE INITIALLY DEFERRED only postpones checks to COMMIT — it fixes insert-ordering issues but does not eliminate validation cost.
  • Raise maintenance_work_mem and max_parallel_maintenance_workers to speed up the rebuild.
  • Always finish with ANALYZE so the planner sees the new data.

Preguntas frecuentes

¿La lección «Aplazamiento de índices y restricciones durante la carga» es gratis?

Sí — el texto completo de «Aplazamiento de índices y restricciones durante la carga» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de PostgreSQL Performance & Query Optimization, actualiza a CoddyKit PRO. El curso de PostgreSQL Performance & Query Optimization incluye 4 lecciones en total.

¿Qué aprenderé en «Aplazamiento de índices y restricciones durante la carga»?

Elimine y reconstruya índices y restricciones alrededor de las cargas masivas para reducir drásticamente la amplificación de escritura. Practicas PostgreSQL Performance & Query Optimization con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar PostgreSQL Performance & Query Optimization?

No se requiere experiencia previa. PostgreSQL Performance & Query Optimization en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.

¿Cuánto tiempo toma la lección «Aplazamiento de índices y restricciones durante la carga»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de PostgreSQL Performance & Query Optimization?

Sí. Cada lección de PostgreSQL Performance & Query Optimization incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Rendimiento de COPY frente a INSERT de varias filas
  2. Aplazamiento de índices y restricciones durante la carga
  3. Ajuste de WAL y checkpoints para la ingesta
  4. Upserts a escala con ON CONFLICT
← Volver a PostgreSQL Performance & Query Optimization