0Pricing
PostgreSQL Performance & Query Optimization · Lesson

Deferring Indexes and Constraints During Load

Drop and rebuild indexes and constraints around bulk loads to slash write amplification.

Deferring Indexes and Constraints During Load is a free PostgreSQL Performance & Query Optimization lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the PostgreSQL Performance & Query Optimization learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

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.

Frequently asked questions

Is the “Deferring Indexes and Constraints During Load” lesson free?

Yes — the full text of “Deferring Indexes and Constraints During Load” is free to read here on the web, and the PostgreSQL Performance & Query Optimization course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the PostgreSQL Performance & Query Optimization course, upgrade to CoddyKit PRO.

What will I learn in “Deferring Indexes and Constraints During Load”?

Drop and rebuild indexes and constraints around bulk loads to slash write amplification. You practise PostgreSQL Performance & Query Optimization with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start PostgreSQL Performance & Query Optimization?

No prior experience is required. PostgreSQL Performance & Query Optimization on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Deferring Indexes and Constraints During Load” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this PostgreSQL Performance & Query Optimization lesson?

Yes. Every PostgreSQL Performance & Query Optimization lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. COPY vs Multi-Row INSERT Throughput
  2. Deferring Indexes and Constraints During Load
  3. Tuning WAL and Checkpoints for Ingestion
  4. Upserts at Scale with ON CONFLICT
← Back to PostgreSQL Performance & Query Optimization