Parallell aggregering och hash-joiner

Kör EXPLAIN på en stor grupperad fråga och leta efter sandwichstrukturen Finalize / Gather / Partial. Noden Gather är där resultaten från workerprocesserna går tillbaka till ledarprocessen.

Observera Workers Planned: den parallellism som planeraren har avsett. Vid körning rapporterar EXPLAIN ANALYZE även Workers Launched, vilket kan vara lägre om systemet har slut på workerplatser.

Planeraren överväger bara parallella planer när vissa GUC:er tillåter det och när tabellen är tillräckligt stor för att det ska löna sig.

• max_parallel_workers_per_gather — maximalt antal workerprocesser som en enskild Gather får använda (0 inaktiverar parallella frågor för den noden).
• max_parallel_workers — gräns för hela instansen.
• max_worker_processes — en hård gräns på operativsystemnivå för alla bakgrundsworkerprocesser.
• min_parallel_table_scan_size (standardvärde 8MB) — tabellen måste vara större än detta för att en parallell genomsökning ska övervägas.
• parallel_setup_cost och parallel_tuple_cost — modellerar kostnaden för att starta workerprocesser och skicka tupler.

På små testtabeller kan planeraren bedöma att parallellismens startkostnad inte lönar sig. För att studera planer kan du kraftigt styra planeraren mot parallellism och sedan mäta på realistiska data.

Om du sätter parallel_setup_cost och parallel_tuple_cost till 0 ignorerar planeraren startkostnaden för workerprocesser, så att den väljer parallella planer även för måttligt stora indata. Detta är ett diagnostiskt knep, inte en inställning för produktion.

En Hash Join bygger en hash-tabell i minnet från den mindre sidan (byggsidan) och slår sedan upp rader från den större sidan i den. I en Parallel Hash Join är själva join-operationen parallellmedveten.

• Plannoden är Parallel Hash Join med en inre nod av typen Parallel Hash.
• Alla workerprocesser samarbetar för att bygga en gemensam hash-tabell i dynamiskt delat minne.
• Därefter slår varje workerprocess upp sin del av den yttre relationen i den gemensamma tabellen.

Detta gör att varje workerprocess slipper bygga en egen privat kopia av hash-tabellen, vilket sparar både CPU och minne.

Var noga med att skilja mellan två planer som ytligt sett liknar varandra:

• Parallel Hash Join (med Parallel Hash): workerprocesserna bygger tillsammans en gemensam hash-tabell. Byggkostnaden och minnet delas.
• Hash Join under Gather (vanlig Hash): varje workerprocess bygger sin egen fullständiga kopia av hash-tabellen. Byggarbetet och minnesåtgången multipliceras med antalet workerprocesser.

För en stor byggsida är den parallellmedvetna varianten mycket billigare. Planeraren väljer den när båda sidorna kan genomsökas parallellt och joinen är parallellsäker.

Hash-joiner och hash-aggregeringar ryms inom work_mem. Om hash-tabellen inte får plats spiller PostgreSQL över till disk i batchar, vilket är mycket långsammare.

I EXPLAIN (ANALYZE, BUFFERS) ska du leta efter Batches: N där N > 1 och Disk Usage på hash-noder — tecken på att work_mem är för litet för byggsidan.

För Parallel Hash kan den gemensamma tabellen använda en större effektiv budget: workerprocessernas tilldelningar av work_mem slås ihop för den gemensamma hash-tabellen, vilket är ytterligare en anledning till att den parallellmedvetna joinen skalar bra.

Planeraren avvisar parallella planer när frågan innehåller parallellosäkra element. Vanliga hinder är:

• Anrop av en funktion som är märkt PARALLEL UNSAFE (standard för användardefinierade funktioner om du inte märker dem).
• Skrivning av data: mål för INSERT, UPDATE och DELETE (den ändrande delen körs seriellt).
• Markörer / radlåsning med FOR UPDATE i många fall.
• max_parallel_workers_per_gather = 0.

Märk rena funktioner utan sidoeffekter som PARALLEL SAFE så att de inte blockerar parallella planer.

Som standard utför ledarprocessen två uppgifter: den samlar både indata från workerprocesserna och hjälper till att köra den parallella planen. Detta styrs av parallel_leader_participation (standardvärde on).

För en fråga med N planerade workerprocesser är den effektiva parallellismen ungefär N+1 när ledarprocessen deltar. Men om ledarprocessen blir en flaskhals när den samlar in ett stort flöde av tupler kan det ibland hjälpa att stänga av deltagandet med off, så att workerprocesserna kan köra utan hinder — mät på båda sätten.

Så här kan du gå tillväga för en CPU-bunden grupperad join:

• Höj max_parallel_workers_per_gather så att planeraren kan dela upp genomsökningen (börja med antalet lediga kärnor).
• Se till att max_parallel_workers och max_worker_processes är tillräckligt höga för att workerprocesserna faktiskt ska startas och inte begränsas.
• Höj work_mem tills hash-noderna visar Batches: 1 (ingen spillning).
• Kontrollera att planen visar Parallel Hash Join + Partial/Finalize Aggregate och att Workers Launched är lika med Workers Planned.

Verifiera alltid med EXPLAIN (ANALYZE, BUFFERS) på data i produktionsstorlek — kostnader i liten skala kan vara missvisande.

Du har lärt dig hur PostgreSQL snabbar upp CPU-bundna grupperingsarbetsbelastningar:

• Parallell aggregering delar upp arbetet i Partial Aggregate per workerprocess och Finalize Aggregate hos ledarprocessen, vilket är möjligt eftersom aggregeringar kan kombineras.
• Parallel Hash Join bygger en gemensam hash-tabell över flera workerprocesser och undviker duplicering av byggkostnad och minne för varje workerprocess.
• Sandwichstrukturen Finalize / Gather / Partial och noder av typen Parallel Hash visar hur du känner igen dessa planer i EXPLAIN.
• Styr parallellismen med max_parallel_workers_per_gather, max_parallel_workers och trösklar för tabellstorlek; dimensionera hash-tabeller med work_mem för att undvika spillning till disk.
• Parallellosäkra funktioner och satser som ändrar data inaktiverar parallella planer; märk rena funktioner som PARALLEL SAFE.

Kontrollera alltid att Workers Launched överensstämmer med Workers Planned och verifiera med EXPLAIN (ANALYZE, BUFFERS) på verkliga data.