HOT-uppdateringar och heap-only-tuple-kedjor

På en sida har varje tuppel en radpekare (item ID). Vid en HOT-uppdatering gäller följande:

• Den nya tuppeln får en ny radpekare och flaggan HEAP_ONLY_TUPLE.
• Den gamla tuppeln får flaggan HEAP_HOT_UPDATED, och dess t_ctid pekar framåt mot den nya tuppeln.
• Indexposter refererar fortfarande till den ursprungliga radpekaren, så en sökning följer kedjan framåt för att hitta den levande versionen.

När VACUUM senare körs kan det rensa kedjan: döda mellanversioner tas bort och rotens radpekare omvandlas till en redirect-pekare direkt till den tuppel som överlevt. Detta kallas HOT-rensning och kan till och med ske opportunistiskt under en normal sidläsning (heap_page_prune).

Ni kan mäta hur många av era uppdateringar som går HOT-vägen. Vyn pg_stat_user_tables visar både det totala antalet uppdaterade tupler och den delmängd som var HOT.

En frisk, skrivintensiv tabell bör ha n_tup_hot_upd nära n_tup_upd. En låg kvot tyder på att uppdateringarna berör indexerade kolumner eller att sidorna är fulla.

Det effektivaste sättet att möjliggöra HOT är att undvika att indexera kolumner som ändras ofta. Varje index över en kolumn i den aktiva skrivvägen tvingar fram icke-HOT-uppdateringar när kolumnen skrivs.

Tänk på en sessionstabell där last_seen_at uppdateras vid varje begäran. Om ni indexerar den blir varje heartbeat en icke-HOT-uppdatering med fullständig indexaktivitet.

• Fråga er: används indexet av en verklig fråga, eller är det spekulativt?
• Kolumner som ändras ofta och har låg selektivitet har sällan någon större nytta av ett btree-index ändå.
• Om ett sådant index tas bort kan en arbetsbelastning omedelbart gå från 0 % HOT till nästan 100 %.

HOT behöver plats på samma sida för den nya tuppeln. Om sidan är fullpackad hamnar den nya versionen på en annan sida och uppdateringen kan inte bli HOT.

fillfactor anger för PostgreSQL hur stor andel av varje sida som ska lämnas tom vid inläsning, så att utrymme reserveras för uppdateringar på samma sida. Standardvärdet för tabeller är 100 (tätt packat), vilket är utmärkt för data som bara läggs till men ogynnsamt för HOT i tabeller som uppdateras ofta.

För tabeller som uppdateras mycket skapar en fillfactor på 70–90 det utrymme som HOT behöver.

Det vinnande receptet för en tabell som uppdateras ofta är att kombinera båda reglerna: håll indexerade kolumner oförändrade och reservera utrymme på sidan.

Här uppdateras en räknartabell hela tiden. Vi indexerar bara den stabila uppslagsnyckeln, aldrig räknaren, och anger en generös fillfactor så att de upprepade uppdateringarna stannar på samma sida.

• Indexet gäller key, som aldrig ändras → villkor 1 är uppfyllt.
• fillfactor = 80 lämnar plats → villkor 2 är uppfyllt.
• Resultat: räknarökningarna blir HOT-uppdateringar utan några indexskrivningar.

HOT-behörighet avgörs av om värdet i någon indexerad kolumn ändrades, inte bara av vanliga btree-kolumner. Detta orsakar ofta problem med:

• Uttrycksindex: ett index på lower(email) innebär att en skrivning till email blockerar HOT även om värdet med gemener logiskt sett är identiskt.
• Partiella index: den indexerade kolumnen deltar fortfarande; en uppdatering av den kan förhindra HOT oavsett WHERE-predikatet.
• Inkluderade kolumner (INCLUDE): i PostgreSQL är kolumner i INCLUDE-satsen också en del av indexet, så ändringar i dem blockerar HOT.

PostgreSQL jämför gamla och nya värden för varje kolumn som refereras av varje index. Om alla är oförändrade tillåts HOT.

Räknarna i pg_stat_user_tables är kumulativa, så Ni kan ta en ögonblicksbild före och efter en känd arbetsbelastning för att bevisa om Er optimering fungerade.

Kör en uppdateringsbatch och jämför sedan förändringen i n_tup_hot_upd med förändringen i n_tup_upd. Om de ökar tillsammans är uppdateringarna helt HOT; om bara n_tup_upd ökar tvingar något fortfarande fram indexuppdateringar.

Minskade indexskrivningar minskar direkt mängden WAL. En uppdatering som inte är HOT loggar heapförändringen och varje indexinsättning; en HOT-uppdatering loggar endast heapförändringen (samt periodvis en post för rensning).

I en belastad tabell med flera index kan HOT-uppdateringar minska WAL-genereringen avsevärt, vilket i sin tur:

• minskar replikeringsfördröjningen på standbys.
• minskar belastningen på checkpoints och bakgrundsskrivaren.
• minskar arkivlagringen för PITR.

Ni kan kvantifiera WAL per sats med pg_stat_statements (wal_bytes) för att se effekten före och efter ändringar av fillfactor och index.

HOT är kraftfullt men fungerar inte överallt. Det hjälper inte när:

• Ni faktiskt behöver uppdatera en indexerad kolumn (till exempel ett statusfält som också används som söknyckel) – indexskrivningen kan inte undvikas, även om Ni ibland kan utforma åtkomstvägen på ett annat sätt.
• Sidorna förblir fulla trots fillfactor eftersom rader växer (till exempel när text med variabel längd eller JSONB expanderar), så att nya versioner hamnar på andra sidor.
• Långvariga transaktioner håller tillbaka xmin-horisonten och förhindrar HOT-rensning, så att kedjor och bloat ändå byggs upp.

Den praktiska strategin är att endast indexera stabila kolumner, ange fillfactor för tabeller med många uppdateringar, hålla transaktionerna korta så att rensningen kan återta utrymme och mäta med n_tup_hot_upd samt WAL-statistik.

Ni vet nu hur Ni utformar scheman och index så att uppdateringar förblir heap-only:

• HOT update = en ny tupel på samma sida, noll indexskrivningar och en HOT-kedja som VACUUM eller rensning senare komprimerar.
• Två villkor: ingen indexerad kolumn får ändras och det måste finnas ledigt utrymme på sidan.
• Regel 1: indexera inte kolumner som ändras ofta eller ligger i den heta körvägen; uttryck, partiella index och INCLUDE-kolumner räknas alla som indexerade.
• Regel 2: ange fillfactor (70–90) för tabeller med många uppdateringar för att reservera utrymme på sidan.
• Mät: sträva efter ett högt förhållande mellan n_tup_hot_upd och n_tup_upd och kontrollera att wal_bytes minskar.
• Begränsningar: växande rader, uppdateringar av genuint indexerade kolumner och långvariga transaktioner kan fortfarande motverka HOT.

Att maximera HOT är en av de mest effektiva och minst riskfyllda förbättringarna för skrivintensiva PostgreSQL-arbetsbelastningar.