0Pricing
PostgreSQL Performance & Query Optimization · Ders

Yükleme Sırasında Dizinleri ve Kısıtlamaları Erteleme

Yığın yüklemelerinin çevresindeki dizinleri ve kısıtlamaları kaldırıp yeniden oluşturarak yazma çoğalmasını büyük ölçüde azaltın.

Yükleme Sırasında Dizinleri ve Kısıtlamaları Erteleme, CoddyKit'te ücretsiz bir PostgreSQL Performance & Query Optimization dersidir. Bu, 4 dersinin 2. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, PostgreSQL Performance & Query Optimization öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. PostgreSQL Performance & Query Optimization kursu toplamda 4 dersten oluşur.

Bu dersin bazı bölümleri henüz çevrilmemiş olup İngilizce olarak gösterilmektedir.

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.

Sıkça Sorulan Sorular

“Yükleme Sırasında Dizinleri ve Kısıtlamaları Erteleme” dersi ücretsiz mi?

Evet — “Yükleme Sırasında Dizinleri ve Kısıtlamaları Erteleme” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve PostgreSQL Performance & Query Optimization kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. PostgreSQL Performance & Query Optimization kursu toplamda 4 dersten oluşur.

“Yükleme Sırasında Dizinleri ve Kısıtlamaları Erteleme” dersinde ne öğreneceğim?

Yığın yüklemelerinin çevresindeki dizinleri ve kısıtlamaları kaldırıp yeniden oluşturarak yazma çoğalmasını büyük ölçüde azaltın. PostgreSQL Performance & Query Optimization ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

PostgreSQL Performance & Query Optimization öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te PostgreSQL Performance & Query Optimization, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 2. dersidir.

“Yükleme Sırasında Dizinleri ve Kısıtlamaları Erteleme” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu PostgreSQL Performance & Query Optimization dersinde kod yazıp çalıştırabilir miyim?

Evet. Her PostgreSQL Performance & Query Optimization dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

  1. COPY ve Çok Satırlı INSERT Aktarım Hızı
  2. Yükleme Sırasında Dizinleri ve Kısıtlamaları Erteleme
  3. Veri Alımı için WAL ve Denetim Noktalarını Ayarlama
  4. ON CONFLICT ile Büyük Ölçekte Upsert
← PostgreSQL Performance & Query Optimization Sayfasına Dön