PostgreSQL Performance & Query Optimization · Lektion

Kostenkonstanten des Abfrageplaners abstimmen

Lernen Sie, wie Kostenkonstanten des Planers wie random_page_cost und effective_cache_size die Planauswahl beeinflussen und wie Sie sie an Ihre Hardware und Daten anpassen.

Kostenkonstanten des Abfrageplaners abstimmen ist eine kostenlose PostgreSQL Performance & Query Optimization-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des PostgreSQL Performance & Query Optimization-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der PostgreSQL Performance & Query Optimization-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

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

Häufig gestellte Fragen

Ist die Lektion „Kostenkonstanten des Abfrageplaners abstimmen“ kostenlos?

Ja — der vollständige Text von „Kostenkonstanten des Abfrageplaners abstimmen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des PostgreSQL Performance & Query Optimization-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der PostgreSQL Performance & Query Optimization-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Kostenkonstanten des Abfrageplaners abstimmen“?

Lernen Sie, wie Kostenkonstanten des Planers wie random_page_cost und effective_cache_size die Planauswahl beeinflussen und wie Sie sie an Ihre Hardware und Daten anpassen. Du übst PostgreSQL Performance & Query Optimization mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um PostgreSQL Performance & Query Optimization zu starten?

Keine Vorkenntnisse erforderlich. PostgreSQL Performance & Query Optimization auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Kostenkonstanten des Abfrageplaners abstimmen“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser PostgreSQL Performance & Query Optimization-Lektion Code schreiben und ausführen?

Ja. Jede PostgreSQL Performance & Query Optimization-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

Wichtige Parameter in postgresql.conf
Speicher optimieren (shared_buffers, work_mem)
Festplatten-I/O und Checkpoints optimieren
Kostenkonstanten des Abfrageplaners abstimmen

← Zurück zu PostgreSQL Performance & Query Optimization