Prestandaoptimering och frågeoptimering i PostgreSQL · Lektion

Partitionsbeskärning vid planering och körning

Läs EXPLAIN-utdata för att bekräfta att statisk beskärning och beskärning vid körning eliminerar irrelevanta partitioner från dina frågor.

Lektion 2 av 413 steg

Partitionsbeskärning vid planering och körning är en gratis lektion i Prestandaoptimering och frågeoptimering i PostgreSQL på CoddyKit. Detta är lektion 2 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för Prestandaoptimering och frågeoptimering i PostgreSQL, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Prestandaoptimering och frågeoptimering i PostgreSQL innehåller totalt 4 lektioner.

Varför partition pruning är viktigt

Ni partitionerade en enorm tabell så att PostgreSQL kan hoppa över partitioner som inte kan innehålla matchande rader. Detta kallas partition pruning.

Utan pruning kan en fråga som berör data från en månad ändå behöva genomsöka varje partition för varje månad. Hela prestandavinsten med partitionering beror på att planeraren (och ibland exekveraren) känner igen vilka partitioner som är relevanta.

Pruning vid planering sker när planeraren redan känner till filtervärdena.
Pruning vid körning sker när värdena blir kända först när frågan körs.

I den här lektionen lär ni er att bekräfta båda varianterna genom att läsa resultatet från EXPLAIN.

Vår exempeltabell

Genom hela lektionen använder vi tabellen events, som är områdespartitionerad per månad på created_at. Varje underpartition innehåller rader från en månad.

Detta är den klassiska tidsserieutformningen där pruning ger störst effekt: frågor gäller vanligtvis ett smalt datumintervall, så de flesta partitioner bör hoppas över helt.

CREATE TABLE events (
    id          bigint        NOT NULL,
    created_at  timestamptz   NOT NULL,
    user_id     bigint        NOT NULL,
    payload     jsonb
) PARTITION BY RANGE (created_at);

CREATE TABLE events_2024_01 PARTITION OF events
    FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');
CREATE TABLE events_2024_02 PARTITION OF events
    FOR VALUES FROM ('2024-02-01') TO ('2024-03-01');
CREATE TABLE events_2024_03 PARTITION OF events
    FOR VALUES FROM ('2024-03-01') TO ('2024-04-01');

Statisk pruning vid planering

När filtret jämför partitionsnyckeln med en konstant kan planeraren avgöra vilka partitioner som ska beröras innan körningen. Detta är statisk pruning (vid planering).

Kör EXPLAIN på en fråga som är begränsad till en månad. Planen bör endast hänvisa till de matchande partitionerna; de andra visas aldrig.

Inställningen enable_partition_pruning (på som standard) styr detta beteende.

EXPLAIN
SELECT count(*)
FROM events
WHERE created_at >= '2024-02-10'
  AND created_at <  '2024-02-20';

Läsa en plan med pruning

Så här ser planen ut för frågan som gäller en enda månad. Lägg märke till att endast events_2024_02 genomsöks. events_2024_01 och events_2024_03 saknas helt i planen.

Append (eller Seq Scan med ett barn) listar endast kvarvarande partitioner.
Partitioner som tagits bort lämnar inga spår i planens resultat.

Detta är den tydligaste bekräftelsen på statisk pruning: räkna partitionerna i planen och jämför med hur många som finns.

Aggregate
  ->  Seq Scan on events_2024_02 events
        Filter: ((created_at >= '2024-02-10'::timestamptz)
             AND (created_at <  '2024-02-20'::timestamptz))

När planen fortfarande listar alla partitioner

Om EXPLAIN visar en Append över alla partitioner tillämpades inte statisk pruning. Vanliga orsaker är:

Filtret hänvisar inte till partitionsnyckeln (till exempel filtrering endast på user_id).
En funktion omsluter nyckeln, till exempel date(created_at) = '2024-02-10', vilket döljer sambandet för planeraren.
Värdet är inte en konstant vid planeringen (parameter eller join-kolumn) — då behövs pruning vid körning.

Låt partitionsnyckeln stå direkt på ena sidan av jämförelsen, så att planeraren kan matcha den mot partitionsgränserna.

-- This DEFEATS static pruning: function wraps the key
EXPLAIN SELECT count(*) FROM events
WHERE date(created_at) = '2024-02-15';

-- This ENABLES it: bare key compared to constants
EXPLAIN SELECT count(*) FROM events
WHERE created_at >= '2024-02-15'
  AND created_at <  '2024-02-16';

Varför parametrar kräver ett annat tillvägagångssätt

Med ett förberett uttryck eller ett värde som tillhandahålls vid körning kanske planeraren inte känner till konstanten när den bygger planen. En generell plan måste förbli giltig för vilket parametervärde som helst och kan därför inte göra statisk pruning.

I stället skjuter PostgreSQL upp beslutet: alla partitioner behålls i planen, men den får möjlighet att hoppa över dem medan frågan körs. Detta är pruning vid körning (runtime pruning).

PREPARE month_count(timestamptz, timestamptz) AS
  SELECT count(*) FROM events
  WHERE created_at >= $1 AND created_at < $2;

EXPLAIN EXECUTE month_count('2024-03-01', '2024-04-01');

Identifiera pruning vid körning i planen

Pruning vid körning syns i EXPLAIN genom två viktiga markörer under en Append-nod:

Subplans Removed: N — partitioner som togs bort innan genomsökningen.
För parameteriserade planer visas en rad som Filter eller initplanparametrar som styr pruning.

Om ni ser Subplans Removed tog exekveraren bort partitioner vid körningen. Om ni varken ser detta eller en reducerad partitionslista skedde ingen pruning.

Aggregate
  ->  Append
        Subplans Removed: 2
        ->  Seq Scan on events_2024_03 events_1
              Filter: ((created_at >= $1) AND (created_at < $2))

Pruning vid körning från nästlade loop-joinningar

Pruning vid körning gäller inte bara parametrar. Den aktiveras också när partitionsnyckeln jämförs med ett värde som produceras av den yttre sidan av en join (en Nested Loop) eller av en underfråga.

Varje yttre rad tillhandahåller ett nyckelvärde, och för varje sådant värde begränsar exekveraren sökningen till den relevanta partitionen. Detta är mycket värdefullt vid selektiva uppslag mot en partitionerad faktatabell.

EXPLAIN (ANALYZE, COSTS OFF)
SELECT e.*
FROM date_filter df
JOIN events e
  ON e.created_at >= df.start_ts
 AND e.created_at <  df.end_ts;

Använd EXPLAIN ANALYZE för att bekräfta att det faktiskt kördes

Vanlig EXPLAIN visar vad som skulle kunna tas bort. Använd EXPLAIN ANALYZE för att bevisa att pruning skedde under en verklig körning — särskilt pruning vid körning.

Subplans Removed: N visas med det faktiska antalet som togs bort under körningen.
Kvarvarande partitioner visar actual rows; partitioner som tagits bort visar (never executed) om de fortfarande finns som undernoder.

Genom att läsa actual time och actual rows för varje partition ser ni exakt vilka barn som utförde arbete.

EXPLAIN (ANALYZE, BUFFERS)
EXECUTE month_count('2024-03-01', '2024-04-01');

Pruning är inte samma sak som constraint exclusion

Äldre versioner av PostgreSQL förlitade sig på constraint_exclusion för partitionering baserad på arv. Modern deklarativ partitionering använder partition pruning, som är snabbare och stöder pruning vid körning.

enable_partition_pruning = on styr den nya mekanismen (vid planering och körning).
constraint_exclusion fungerade endast vid planering och endast med CHECK-begränsningar.

För deklarativa partitioner ska ni låta enable_partition_pruning vara på och inte förlita er på constraint_exclusion.

SHOW enable_partition_pruning;   -- expect: on
SHOW constraint_exclusion;        -- 'partition' (legacy default)

En praktisk checklista

När Ni verifierar partition pruning med en verklig fråga går Ni igenom följande lista:

Finns partitioneringsnyckeln i predikatet, utan omslutning och SARGable? Inga omslutande funktioner och inga implicita typkonverteringar som hindrar matchning.
Statiskt fall: kör EXPLAIN — försvinner de bortfiltrerade partitionerna från planen?
Körningsfall: leta efter Subplans Removed: N under Append.
Bekräfta med EXPLAIN ANALYZE att endast de förväntade partitionerna faktiskt bearbetades.
Kontrollera inställningen om ingen partition pruning sker: enable_partition_pruning måste vara aktiverad.

Snabbkontroll

Ett prepared statement filtrerar en range-partitionerad tabell på dess partitioneringsnyckel med hjälp av en bunden parameter. Ni kör EXPLAIN ANALYZE EXECUTE och vill bekräfta att partition pruning ägde rum.

Besvara frågan i den interaktiva lektionen

Sammanfattning

Ni kan nu bekräfta partition pruning i resultatet från EXPLAIN:

Statisk partition pruning sker vid planeringen när partitioneringsnyckeln jämförs med konstanter; bortfiltrerade partitioner försvinner helt enkelt från planen.
Partition pruning vid körning hanterar parametrar och värden från joiner; leta efter Subplans Removed: N under Append.
Håll partitioneringsnyckeln utan omslutning och SARGable — om Ni omsluter den i en funktion förhindras partition pruning.
Använd EXPLAIN ANALYZE för att visa vilka partitioner som faktiskt bearbetades, och kontrollera att enable_partition_pruning är aktiverad när ingen partition pruning sker.

När Ni lär Er att läsa dessa markörer går partitionering från en förhoppningsfull design till en verifierad prestandavinst.

Gratis att börja

Lär dig SQL med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser: 22
Lektioner: 88

Börja lära dig gratis Visa hela kursen

Vanliga frågor

Är lektionen ”Partitionsbeskärning vid planering och körning” gratis?

Ja – du kan läsa vilka 3 lektioner som helst i lärvägen Prestandaoptimering och frågeoptimering i PostgreSQL, inklusive ”Partitionsbeskärning vid planering och körning”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i Prestandaoptimering och frågeoptimering i PostgreSQL innehåller totalt 4 lektioner.

Vad lär jag mig i ”Partitionsbeskärning vid planering och körning”?

Läs EXPLAIN-utdata för att bekräfta att statisk beskärning och beskärning vid körning eliminerar irrelevanta partitioner från dina frågor. Ni övar på Prestandaoptimering och frågeoptimering i PostgreSQL med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Prestandaoptimering och frågeoptimering i PostgreSQL?

Du behöver inga förkunskaper. Utbildningen i Prestandaoptimering och frågeoptimering i PostgreSQL på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 2 av 4.

Hur lång tid tar lektionen ”Partitionsbeskärning vid planering och körning”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Prestandaoptimering och frågeoptimering i PostgreSQL-lektionen?

Ja. Varje Prestandaoptimering och frågeoptimering i PostgreSQL-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

Välja partitionsnyckel och strategi
Partitionsbeskärning vid planering och körning
Automatisera skapande och kvarhållning av partitioner
Migrera en enorm tabell till partitioner online

← Tillbaka till Prestandaoptimering och frågeoptimering i PostgreSQL