PostgreSQL Performance & Query Optimization · Lezione

Regolare le costanti di costo del query planner

Impari come costanti di costo del planner quali random_page_cost ed effective_cache_size influenzano la scelta del piano e come regolarle in base all'hardware e ai dati.

Lezione 4 di 413 passaggi

Regolare le costanti di costo del query planner è una lezione PostgreSQL Performance & Query Optimization gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento PostgreSQL Performance & Query Optimization, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso PostgreSQL Performance & Query Optimization include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

The Planner Needs Hints About Hardware

The planner estimates the cost of each plan using constants that model your hardware. If those constants do not match reality, it may pick a sequential scan when an index scan would be far faster, or vice versa.

seq_page_cost vs random_page_cost

Two key constants:

  • seq_page_cost (default 1.0): cost to read a page sequentially
  • random_page_cost (default 4.0): cost to read a page at random

The 4:1 ratio assumes spinning disks where random reads are slow.

Tuning for SSDs

On SSDs random reads are nearly as cheap as sequential ones. Lowering random_page_cost makes the planner favor index scans appropriately.

SET random_page_cost = 1.1;

effective_cache_size

This tells the planner how much memory the OS and PostgreSQL together are likely to use for caching data. It does not allocate memory — it only influences cost estimates for index scans.

SET effective_cache_size = '12GB';

Why effective_cache_size Matters

A large value tells the planner that repeated index lookups will likely hit cache, making index scans look cheaper and more attractive for large tables. Set it to roughly 50-75% of total RAM.

CPU Cost Constants

Finer constants weigh CPU work:

  • cpu_tuple_cost: per-row processing
  • cpu_index_tuple_cost: per index entry
  • cpu_operator_cost: per operator/function call

These are rarely changed but matter for CPU-heavy expressions.

Testing a Change at Session Level

Test constants with SET in your session before making them permanent. Compare plans with EXPLAIN.

SET random_page_cost = 1.1;
EXPLAIN SELECT * FROM orders WHERE customer_id = 42;

Making It Permanent

Once satisfied, set the value cluster-wide and reload, or edit postgresql.conf.

ALTER SYSTEM SET random_page_cost = 1.1;
SELECT pg_reload_conf();

Beware of Over-Tuning

Do not chase a single slow query by skewing constants globally — you may break thousands of other plans. Fix the root cause (missing index, stale stats) first; adjust constants only for genuine hardware mismatches.

Per-Tablespace Tuning

If some data sits on SSD and some on HDD, you can set random_page_cost per tablespace so the planner reasons about each storage medium correctly.

ALTER TABLESPACE fast_ssd
SET (random_page_cost = 1.1);

Verifying the Effect

After changing a constant, confirm the planner actually switched plans. Run EXPLAIN before and after and look for a Seq Scan turning into an Index Scan (or vice versa).

EXPLAIN SELECT * FROM orders WHERE customer_id = 42;
SET random_page_cost = 1.1;
EXPLAIN SELECT * FROM orders WHERE customer_id = 42;

Quick Check

Test your planner-tuning knowledge.

Recap

You learned planner cost tuning:

  • Cost constants model your hardware for the planner
  • Lower random_page_cost on SSDs to favor index scans
  • Set effective_cache_size to ~50-75% of RAM
  • Test with SET and EXPLAIN before ALTER SYSTEM
  • Fix indexes/stats before skewing constants globally
Gratis per iniziare

Impara SQL con un tutor IA — gratis

Scrivi ed esegui vero codice nel tuo browser, ricevi aiuto istantaneo da un tutor IA disponibile 24/7, e riprendi da dove hai lasciato sul web o nell'app.

Corsi
22
Lezioni
88

Domande Frequenti

La lezione «Regolare le costanti di costo del query planner» è gratuita?

Sì — il testo completo di «Regolare le costanti di costo del query planner» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso PostgreSQL Performance & Query Optimization, passa a CoddyKit PRO. Il corso PostgreSQL Performance & Query Optimization include 4 lezioni in totale.

Cosa imparerò in «Regolare le costanti di costo del query planner»?

Impari come costanti di costo del planner quali random_page_cost ed effective_cache_size influenzano la scelta del piano e come regolarle in base all'hardware e ai dati. Eserciti PostgreSQL Performance & Query Optimization con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare PostgreSQL Performance & Query Optimization?

Non è richiesta alcuna esperienza precedente. PostgreSQL Performance & Query Optimization su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.

Quanto tempo richiede la lezione «Regolare le costanti di costo del query planner»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione PostgreSQL Performance & Query Optimization?

Sì. Ogni lezione PostgreSQL Performance & Query Optimization include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Parametri principali di postgresql.conf
  2. Ottimizzazione della memoria (shared_buffers, work_mem)
  3. Ottimizzazione di I/O del disco e checkpoint
  4. Regolare le costanti di costo del query planner
← Torna a PostgreSQL Performance & Query Optimization