Postgres: paisumine, pg_repack ja edasilükatud constraints

Tabelite ja indeksite paisumise mõju (bloat) on laialdaselt tuntud ja esineb mitte ainult Postgreses. On viisid selle vastu võitlemiseks „kastist välja“ nagu VACUUM FULL või CLUSTER, kuid need blokeerivad tabelid töötamise ajal ja seetõttu ei saa neid alati kasutada.

Selles artiklis on veidi teooriat selle kohta, kuidas paisumine tekib, kuidas sellega saab võidelda, edasilükatud constraints ja probleemid, mida nad toovad kaasa pg_repacki laienduse kasutamisel.

See artikkel on kirjutatud minu esitluse põhjal minu esitusel PgConf.Russia 2020-l.

Kuidas paisumine tekib

Postgres põhineb mitmeversioonilisel mudelil (MVCC). Selle olemus seisneb selles, et igal tabelis oleval real võib olla mitu versiooni, samal ajal kui tehingud näevad mitte rohkem kui ühte neist versioonidest, kuid see ei pea olema tingimata sama. See võimaldab mitme tehingu samal ajal töötada ja peaaegu mitte üksteist mõjutada.

Selge on see, et kõik need versioonid tuleb salvestada. Postgres töötab mälu lehekülgede kaupa ja leht on minimaalne andmemaht, mida saab lugeda kettalt või kirjutada. Vaatame väikest näidet, et mõista, kuidas see juhtub.

Oletame, et meil on tabel, kuhu oleme lisanud mitu rekordit. Faili esimesel leheküljel, kuhu tabelit salvestatakse, on ilmunud uued andmed. Need on aktiivsed rida versioonid, mis on teistele tehingutele kättesaadavad pärast kinnitamist (kerguse huvides oletame, et isolatsioonitase on Read Committed).

Seejärel uuendasime ühte rekordit, mille tulemusel tähistasime vana versiooni aegunuks.

Samm-sammult, uuendades ja kustutades rida versioone, saime lehe, kus umbes pool andmetest on „prügi“. Need andmed ei ole ühelegi tehingule nähtavad.

Postgreses on mehhanism VACUUM, mis puhastab aegunud versioonid ja vabastab ruumi uutele andmetele. Kuid kui see pole piisavalt agressiivselt seadistatud või on hõivatud teiste tabelitega töötamisega, jäävad „prügised andmed“ alles ja me peame kasutama lisalehti uute andmete jaoks.

Nii et meie näites koosneb tabel mõnel ajahetkel neljast lehelt, kuid selles on ainult pool aktiivsetest andmetest. Tulemuseks on see, et tabelile juurdepääsuks loeme palju rohkem andmeid, kui on vajalik.

Isegi kui VACUUM eemaldab kõik aegunud ridade versioonid, ei parane olukord dramaatiliselt. Meil on olemas vaba ruum lehtedel või isegi terveid lehti uute ridade jaoks, kuid me loeme endiselt rohkem andmeid, kui vajalik.
Muide, kui täiesti tühi leht (meie näites teine) oleks faili lõpus, saaks VACUUM selle kärpida. Kuid praegu asub see keskel, seega ei saa me sellega midagi teha.

Kui selliste tühi või tugevasti tühjendatud lehtede arv suureneb, mida tuntakse kui bloat, hakkab see mõjutama jõudlust.

Kõik eelnevalt kirjeldatud on bloati tekkimise mehhanism tabelites. Indeksites toimub see ligikaudu samamoodi.

Kas mul on bloat?

On mitmeid viise, kuidas teada saada, kas teil on bloat. Esimese idee on kasutada Postgrase sisestatistikat, kus on ligikaudne teave tabelites ridade arvu, 'elus' ridade arvu jne kohta. Internetist on võimalik leida palju variatsioone juba valmis skripte. Meie alus on skripti PostgreSQL Expertsilt, mis suudab hinnata tabelite bloati koos toast ja bloat btree-indeksitega. Meie kogemuse kohaselt on selle täpsus 10-20%.

Teine viis on kasutada laiendust pgstattuple, mis võimaldab vaadata lehtede sisu ja saada nii hindelisi kui ka täpseid bloati väärtuseid. Kuid teisel juhul tuleb kogu tabel skaneerida.

Väike bloati väärtus, kuni 20%, on meie arvates vastuvõetav. Seda võib pidada sarnaseks fillfactor’iga tabelitele ja indeksitele. Kui see ületab 50%, võivad tekkida jõudlusprobleemid.

Viise bloati vastu võitlemiseks

Postgresis on mitmeid viise bloatiga võitlemiseks 'kastist välja', kuid need ei sobi alati ega kõigile.

Konfigureerida AUTOVACUUM, et bloat ei tekiks. Ja kui olla täpsem, et see püsiks teie jaoks vastuvõetaval tasemel. Tundub, et see on “kapteni” nõuanne, kuid tegelikult ei ole seda alati kerge saavutada. Näiteks, kui teete aktiivset arendust, kus andmemudelit pidevalt muudate, või kui toimub mingi andmete migreerimine. Selle tulemusena võib teie koormuse profiil sageli muutuda ja üldiselt on see erinev erinevate tabelite jaoks. Seega peate pidevalt natuke ette tegutsema ja kohandama AUTOVACUUMi vastavalt iga tabeli muutuvatele profiilidele. Kuid on ilmne, et seda ei ole lihtne teha.

Teine levinud põhjus, miks AUTOVACUUM ei suuda tabeleid töödelda, on pikaajalised tehingud, mis ei luba tal andmeid puhastada, kuna need on nendele tehingutele kergesti ligipääsetavad. Soovitus siin on samuti ilmne – vabaneda “riputatud” tehingutest ja minimeerida aktiivsete tehingute aega. Kuid kui teie rakenduse koormus on OLAP-i ja OLTP-i hübriid, võib teil samaaegselt olla nii palju sagedasi värskendusi ja lühikesi päringuid kui ka pikka aega kestev tegevus – näiteks mõne aruande koostamine. Sellises olukorras tuleks mõelda koormuse jaotamisele erinevatesse andmebaasidesse, mis võimaldab neid paremini seadistada.

Veel üks näide – isegi kui profiil on ühtlane, kuid andmebaas on väga kõrge koormuse all, võib isegi kõige agressiivsem AUTOVACUUM mitte hakkama saada ja bloat võib tekkida. Skaleerimine (vertikaalne või horisontaalne) on ainus lahendus.

Mida aga teha olukorras, kus olete AUTOVACUUMi seadnud, kuid bloat jätkab kasvu.

Meeskond VACUUM FULL koostab tabelite ja indeksite sisu ümber ning jätab neisse ainult asjakohased andmed. Bloat'i kõrvaldamiseks töötab see ideaalselt, kuid selle täitmise ajal saadakse tabelile eriline lukustus (AccessExclusiveLock), mis ei luba selle tabeli päringute täitmist, isegi select'e. Kui saate endale lubada teenuse või selle osa peatamist mõneks ajaks (kümnetest minutitest mitme tunnini, olenevalt andmebaasi suurusest ja teie seadmetest), siis on see variant parim. Kahjuks ei jõua me VACUUM FULL-i teha kavandatud hooldusaegade jooksul, seega see meetod ei sobi meile.

Meeskond CLUSTER taaskordab tabeli sisu nagu VACUUM FULL, võimaldades samas näidata indeksit, mille alusel andmed füüsiliselt kettale järjestatakse (kuid tulevikus ei tagata uute ridade järjekorda). Teatud olukordades on see hea optimeerimine mitmete päringute jaoks – indeksi kaudu mitme salvestuse lugemisega. Selle käsu puudus on sama, mis VACUUM FULL-l – see lukustab tabeli töö ajal.

Meeskond REINDEX on sarnane eelnevatele, kuid see teostab konkreetse indeksi või kõikide tabeli indeksite ümberkorraldamise. Lukustused on veidi nõrgemad: ShareLock tabelil (takistab modifikatsiooni, kuid võimaldab select teadet) ja AccessExclusiveLock ümberkorraldataval indeksil (blokeerib selle indeksi kasutavaid päringuid). Kuid PostgreSQL versioonis 12 ilmus parameeter CONCURRENTLY, mis võimaldab indeksi ümberkorraldamist, blokeerimata samal ajal paralleelset rekordite lisamist, muutmist või kustutamist.

Varem PostgreSQL versioonides võis saavutada tulemuse, mis on sarnane REINDEX CONCURRENTLY-le, kasutades CREATE INDEX CONCURRENTLY. See võimaldab luua indeksi ilma range blokeerimiseta (ShareUpdateExclusiveLock, mis ei sega paralleelseid päringuid), seejärel asendada vana indeks uuega ja eemaldada vana indeks. See aitab kõrvaldada indeksite bloat'i, segamata teie rakenduse tööd. Oluline on märkida, et indeksite ümberkorraldamise ajal on kettasüsteemile täiendav koormus.

Seega, kui indeksite jaoks on olemas viise bloat'i „kuumalt” kõrvaldamiseks, siis tabelite jaoks neid ei ole. Siia tulevad erinevad välised laiendused: pg_repack (varasemalt pg_reorg), pgcompact, pgcompacttable ja teised. Käesolevas artiklis ei hakka ma neid võrreldama ja räägin ainult pg_repack'ist, mida pärast teatud töötlemist kasutame.

Kuidas pg_repack töötab

Kujutage ette, et meil on täiesti tavaline tabel – indeksite, piirangute ja, kahjuks, bloat'iga. Esimeseks sammuks loob pg_repack logitabeli, et salvestada teavet kõigi muudatuste kohta töö ajal. Trigger replikeerib need muudatused igal lisamisel, uuendamisel ja kustutamisel. Seejärel luuakse tabel, mis on struktuurilt algsega sarnane, kuid ilma indeksite ja piiranguteta, et mitte aeglustada andmete sisestamise protsessi.

Seejuhul pg_repack kannab vana tabeli andmed uude tabelisse, filtreerides automaatselt välja kõik ebatäiendavad read, seejärel loob uue tabeli jaoks indeksid. Kõigi nende toimingute käigus koguneb logitabelisse muudatusi.

Järgmine samm on viia muudatused uude tabelisse. Üleviimine toimub mitmes iteratsioonis ja kui logitabelis on alle 20 kirjet, haarab pg_repack ranged lukustuse, viib viimased andmed üle ja asendab vana tabeli uuega PostgreSQLi süsteemitabelites. See on ainus ja väga lühike aeg, mil te ei saa tabeliga töötada. Pärast seda eemaldatakse vana tabel ja logitabel ning failisüsteemis vabastatakse ruum. Protsess on lõpetatud.

Teoorias näeb kõik suurepärane välja, aga kuidas on praktikas? Testisime pg_repacki ilma koormata ja koormuse all, kontrollisime selle töö tõhusust varajase katkestamise korral (lihtsalt öeldes, Ctrl+C abil). Kõik testid olid positiivsed.

Käisime produtseerimisprotsessis — ja siin ei läinud kõik nii, nagu ootasime.

Esimene ebaõnnestumine tootmises

Esimesel klastril saime unikaalsuse piirangu rikkumise vea:

$ ./pg_repack -t tablename -o id
INFO: tabeli "tablename" repakkimine
ERROR: päring ebaõnnestus: 
    ERROR: dubleeritud võti rikub unikaalset piirangut "index_16508"
DETAIL: Võti (id, index)=(100500, 42) juba eksisteerib.

See piirang oli automaatselt genereeritud nimega index_16508 – selle lõi pg_repack. Tema koostisosade järgi määrasime, et see on "meie" piirang, mis vastab sellele. Probleem oligi selles, et see ei olnud tavaline piirang, vaid edasi lükatud (deferred constraint), st selle kontrollimine toimub hiljem kui SQL käsk, mis toob kaasa ootamatud tagajärjed.

Edasi lükatud piirangud: miks need vajalikud on ja kuidas need töötavad

Veidi teooriat edasi lükatud piirangutest.
Vaatame lihtsat näidet: meil on autode viidatud tabel, millel on kaks attribuuti – nimi ja auto järjestus viidatud tabelis.

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique
);

Kujutame ette, et peame esimesed ja teised autod omavahel vahetama. Raskete lahendus – uuendada esimene väärtus teiseks ja teine esimesele:

begin;
  update cars set ord = 2 where name = 'audi';
  update cars set ord = 1 where name = 'bmw';
commit;

Kuid selle koodi teostamisel saame ootuspäraselt piirangu rikkumise, sest tabelis väärtuste järjekord on unikaalne:

[23305] VIGA: duplikaadi võtme väärtus rikub unikaalse piirangu “uk_cars”\nDetail: Key (ord)=(2) juba eksisteerib.

Kuidas teha teisiti? Esimene variant: lisada täiendav väärtuse vahetus, mille järjekord kindlasti ei eksisteeri tabelis, näiteks “-1”. Programmeerimises nimetatakse seda “kaks muutuja väärtuse vahetamiseks kolmanda kaudu”. Ainus puudus selle meetodi juures on täiendav värskendus.

Teine variant: projekti ümberkujundamine, et kasutada järjekorra väärtuse jaoks ujuva komaga andmetüüpi terve arvu asemel. Siis uuendades väärtust 1-st näiteks 2.5 ni, asetub esimene kirje automaatselt teise ja kolmanda vahele. See lahendus töötab, kuid on kaks piirangut. Esiteks, see ei sobi teile, kui väärtust kasutatakse kuskil liideses. Teiseks, sõltuvalt andmetüübi täpsusest, on teil piiratud arv võimalikke lisamisi enne, kui peate kõikide kirjete väärtused uuesti arvutama.

Kolmas variant: muuta piirang tingimuseks, et seda kontrollitakse ainult pühendamise hetkel:

create table cars\n(\n  name text constraint pk_cars primary key,\n  ord integer not null constraint uk_cars unique deferrable initially deferred\n);

Kuna meie algse küsimuse loogika garanteerib, et pühendamise hetkeks on kõik väärtused unikaalsed, siis see õnnestub.

Ülaltoodud näide on kindlasti väga sünteetiline, kuid idee väljendatakse. Meie rakenduses kasutame paindlikke piiranguid loogika rakendamiseks, mis haldab konflikte, kui kasutajad töötavad samaaegselt ühiste objektide-widgetitega tahvlil. Selliste piirangute kasutamine võimaldab meil rakenduskoodi veidi lihtsamaks teha.

Üldiselt, sõltuvalt Postgresi piirangu tüübist, on nende kontrollimiseks kolm tasemete granulariteeti: rea, tehingu ja väljendi tase.

Allikas: begriffs

CHECK ja NOT NULL kontrollitakse alati rea tasemel, teiste piirangute jaoks, nagu tabelist näha, on erinevad variandid. Üksikasjalikumalt saab lugeda siin.

Kokkuvõttes annavad edasilükatud piirangud teatavates olukordades parema loetavuse ja vähem käske. Kuid selle eest tuleb maksta debugeerimisprotsessi keerukuse eest, kuna vea esinemise hetk ja hetk, mil te sellest teada saate, on ajas eraldatud. Veel üks võimalik probleem on seotud sellega, et planeerija ei suuda alati optimeeritud plaani koostada, kui päringus on edasilükatud piirang.

pg_repacki täiendamine

Oleme arutanud, mis on edasilükatud piirangud, kuid kuidas need on seotud meie probleemiga? Tuletame meelde viga, mille me varem saime:

$ ./pg_repack -t tablename -o id
INFO: tabeli "tablename" repakkimine
ERROR: päring ebaõnnestus: 
    ERROR: dubleeritud võti rikub unikaalset piirangut "index_16508"
DETAIL: Võti (id, index)=(100500, 42) juba eksisteerib.

See tekib andmete kopeerimisel logitabelist uude tabelisse. See näeb välja kummaline, kuna logitabeli andmed kinnitatakse koos algse tabeli andmetega. Kui nad vastavad algse tabeli piirangutele, siis kuidas nad saavad rikkuda samu piiranguid uues tabelis?

Nagu selgus, peitub probleemi juur pg_repacki varasemas etapis, kus luuakse ainult indeksid, mitte piirangud: vanas tabelis oli unikaalne piirang, aga uues loodi selle asemel unikaalne indeks.

Siin on oluline märkida, et kui piirang on tavaline, mitte edasilükatud, siis selle asemel loodud unikaalne indeks on samaväärne selle piiranguga, kuna Postgresis rakendatakse unikaalseid piiranguid unikaalse indeksi loomise kaudu. Kuid edasilükatud piirangu puhul ei ole käitumine sama, kuna indeks ei saa olla edasilükatud ja seda kontrollitakse alati SQL-käsu täitmise hetkel.

Nii et probleemi olemus seisneb „edasilükatud” kontrollis: algses tabelis toimub see kinnitamisel, aga uues - SQL-käsu täitmisel. Seega peame tegema nii, et kontrollid toimuksid mõlemas juhul ühtemoodi: kas alati edasilükatult või alati kohe.

Nii et, millised ideed meil olid.

Luua indeks, mis on sarnane edasilükatule

Esimene idee on teha mõlemad kontrollid kohe. See võib tekitada mitmeid valepositiivseid piiranguid, kuid kui neid on vähe, ei tohiks see kasutajate tööd mõjutada, kuna sellised konfliktid on neile normaalsed. Need esinevad näiteks siis, kui kaks kasutajat hakkavad samal ajal ühte ja sama vidinat redigeerima ning teise kasutaja klient ei saa infot, et vidin on juba esimesest kasutajast redigeerimiseks lukustatud. Sellises olukorras reageerib server teisele kasutajale keeldumisega ning tema klient tühistab muudatused ja lukustab vidina. Hiljem, kui esimene kasutaja lõpetab redigeerimise, saab teine teate, et vidin ei ole enam lukus, ja saab oma toimingut korrata.

Kuna tegemist oli alati prioriteetse režiimiga, lõime uue indeksi, mis on sarnane originaalsele viivitatud piirangule:

CREATE UNIQUE INDEX CONCURRENTLY uk_tablename__immediate ON tablename (id, index);
-- käivita pg_repack
DROP INDEX CONCURRENTLY uk_tablename__immediate;

Testkeskkonnas saime ainult mõned oodatud vead. Edu! Taaskäivitasime pg_repack tootmises ja saime ühe tunni töö jooksul esimeses klastris 5 viga. See on vastuvõetav tulemus. Kuid juba teises klastris kasvas vigade arv kordades ja pidime pg_repacki peatama.

Miks see juhtus? Veaoht sõltub sellest, kui paljud kasutajad töötavad samade vidinatega samal ajal. Tundub, et esimeses klastris oli andmete seas palju vähem konkurentsivõimelisi muudatusi, kui teistes, st lihtsalt “õnnestus”.

Idee ei töötanud. Sel ajal nägime kahte muud lahenduse varianti: meie rakenduskoodi ümber kirjutamine, et loobuda viivitatud piirangutest, või pg_repack'i “õpetamine” nendega töötama. Valisime teise variandi.

Asenda uue tabeli indeksid algse tabeli viivitatud piirangutega.

Töötamise eesmärk oli ilmne – kui algsel tabelil on viivitatud piirang, siis tuleks uue jaoks luua selline piirang, mitte indeks.

Meie muudatuste kontrollimiseks kirjutasime lihtsa testi:

• tabel viivitatud piiranguga ja ühe kirje;
• sisestame tsüklis andmed, mis konkureerivad olemasoleva kirje vastu;
• teeme uuenduse – andmed ei ole enam vastuolus;
• komitee muudatused.

create table test_table
(
  id serial,
  val int,
  constraint uk_test_table__val unique (val) deferrable initially deferred 
);

INSERT INTO test_table (val) VALUES (0);
FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (0) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    COMMIT;
  END;
END LOOP;

Esialgne versioon pg_repack kukkus alati esimesel insert'il, parendatud versioon töötas ilma vigadeta. Suurepärane.

Liigume tootmisse ja saame jälle vea samas faasis, kui kopeerime andmeid logitabelist uude:

$ ./pg_repack -t tablename -o id
INFO: tabeli "tablename" repakkimine
ERROR: päring ebaõnnestus: 
    ERROR: dubleeritud võti rikub unikaalset piirangut "index_16508"
DETAIL: Võti (id, index)=(100500, 42) juba eksisteerib.

Klassikaline olukord: testkeskkondades töötab kõik, aga tootmises ei?!

APPLY_COUNT ja kahe partii kohtumine

Alustasime koodi analüüsimist sõna-sõnalt ja avastasime olulise hetke: andmete ülekandmine logitabelist uude toimub partiitena, konstants APPLY_COUNT näitas partii suurust:

for (;;)
{
num = apply_log(connection, table, APPLY_COUNT);

if (num > MIN_TUPLES_BEFORE_SWITCH)
     continue;  
/* there might be still some tuples, repeat. */
...
}

Probleem on selles, et algse tehingu andmed, kus mitu toimingut võivad potentsiaalselt piirangut rikkuda, võivad ülekandmisel sattuda kahe partii vahele – pool käske kinnitatakse esimeses parteis ja teine pool teises. Siin võib minna nii, et kui esimeses parteis ei rikkuda midagi, siis on kõik korras, aga kui rikutakse – toimub viga.

APPLY_COUNT on 1000 kirjet, mis selgitab, miks meie testid läksid edukalt – nad ei katnud juhtumit “partii kohtumisest”. Kasutasime kahte käsku – insert ja update, seega täpselt 500 tehingut kahe käskuga mahtusid alati partii, ega kogenud probleeme. Pärast teise uuenduse lisamist lõpetas meie muudatus töötamise:

FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (1) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    UPDATE test_table set val = i where id = v_id; -- üks uuendus veel
    COMMIT;
  END;
END LOOP;

Nii et järgmine ülesanne – teha nii, et andmed algsest tabelist, mis muutuvad ühes tehingus, jaguks ka uude tabelisse samas tehingus.

Partii kasutamisest loobumine

Ja meil oli taas kaks lahendust. Esimene: loobume üldse partiide jagamisest ja teeme andmete ülekande ühe tehinguga. Selle lahenduse kasuks rääkis selle lihtsus – vajalikud koodimuudatused on minimaalsed (muide, vanemates versioonides töötas pg_reorg tookord just nii). Kuid probleem on see, et loome pikaajalise tehingu, ja see, nagu varem öeldud, on oht uue bloat'i tekkeks.

Teine lahendus – keerulisem, kuid ilmselt õigem: luua logitabelis veerg, mis sisaldab selle tehingu identifikaatorit, mis lisas andmed tabelisse. Sel juhul saame andmete kopeerimise ajal neid selle atribuudi järgi grupeerida ja tagada, et seotud muudatused kantakse üle koos. Partii koosneb mitmest tehingust (või ühest suurest) ja selle suurus varieerub sõltuvalt sellest, kui palju andmeid nende tehingute käigus muudeti. Oluline on märkida, et kuna erinevate tehingute andmed satuvad logitabelisse juhuslikus järjekorras, ei saa seda enam lugeda järjestikku nagu varem. seqscan iga päringu puhul, kus filtrimine toimub tx_id järgi – on liiga kallis, vajalik on indeks, kuid see aeglustab meetodi tööd kulude tõttu selle uuendamisel. Ühesõnaga, nagu alati, tuleb millegagi ofreerida.

Nii et otsustasime alustada esimesest variandist, kuna see oli lihtsam. Esiteks oli vaja mõista, kas pikk tehing on tõsine probleem. Kuna andmete põhiasi ülekande vanast tabelist uude toimub samuti ühe pikaajalise tehingu käigus, siis küsimus muutus küsimuseks: “kui palju me suurendame seda tehingut?” Esimese tehingu kestus sõltub peamiselt tabeli suurusest. Uue kestus sõltub sellest, kui palju muudatusi koguneb tabelisse andmete ülekande ajal, st koormuse intensiivsusest. pg_repack käivitamine toimus teenuse minimaalsete koormuste ajal ning muudatuste hulk oli võrreldes algse tabeli suurusega võrreldamatult väike. Otsustasime, et saame uue tehingu kestuse ignoreerida (keskmiselt on see 1h ja 2-3 minutit).

Eksperimendid olid positiivsed. Käivitamine tootmises samuti. Selguse huvides – pilt ühe andmebaasi suurusest pärast käitamist:

Kuna see lahendus rahuldas meid täielikult, ei proovinud me teist rakendust, kuid kaalume selle arutamist laienduse arendajatega. Kahjuks ei ole meie praegune täiendus veel avaldamiseks valmis, kuna lahendasime probleemi ainult ainulaadsete edasi lükatud piirangutega, kuid täieliku plaani jaoks on vaja toetada ka muid tüüpe. Loodame, et suudame seda tulevikus teha.

Võib-olla tekkis teil küsimus, miks me üldse sellesse pg_repacki täiustamisse sukeldusime, mitte ei kasutanud näiteks selle analooge? Mõnes etapis mõtlesime ka sellele, kuid varasem positiivne kogemus selle kasutamisest edasi lükatud piiranguteta tabelitel motiveeris meid probleemi olemust mõistma ja selle parandamiseks pingutama. Lisaks sellele nõuab teiste lahenduste kasutamine samuti aega testimiseks, seetõttu otsustasime, et proovime esmalt probleemi selles lahenduses lahendada, ja kui mõistame, et ei suuda seda mõistliku aja jooksul teha, siis hakkame kaaluma analooge.

Järeldused

Mida me saame soovitada oma kogemuste põhjal:

1. Jälgige oma bloat'i. Jälgimise andmete põhjal saate aru, kui hästi on autovacuum seadistatud.
2. Seadistage AUTOVACUUM, et hoida bloat lubatud tasemel.
3. Kui bloat siiski kasvab ja te ei saa seda ‘karbist välja’ vahenditega võita, ärge kartke kasutada välist laiendust. Peamine on kõik põhjalikult testida.
4. Ärge kartke täiustada väliseid lahendusi vastavalt oma vajadustele – mõnikord võib see olla efektiivsem ja isegi lihtsam kui teie enda koodi muutmine.

Allikas: habr.com