Skip scan oferă unui index un rol nou, în anumite condiții

O îmbunătățire a planificatorului ar trebui să redeschidă o decizie despre indecși, nu să o rezolve automat. Skip scan din PostgreSQL 18 oferă unor indecși B-tree compuși o cale mai utilă pentru interogările fără o condiție de egalitate pe prima coloană. Dacă această cale face redundant un alt index depinde de utilizarea bazei. Păstrați indexul dedicat până când o comparație explică ce ar câștiga și ce ar pierde aplicația prin eliminarea lui.

Privind retrospectiv din noiembrie 2026, PostgreSQL 18 Beta 1 a fost anunțat la 8 mai 2025. Proiectul cerea testarea operațiilor obișnuite și recomanda explicit să nu fie folosită acea versiune beta în producție. Prezentarea funcționalității skip scan invita la evaluarea unei versiuni preliminare. Nu afirma că o versiune stabilă PostgreSQL 18 fusese deja lansată în acea săptămână.

Lipsa condiției pe prima coloană contează în continuare

Un index B-tree ordonează înregistrările după cheile sale. Un index care începe cu regiunea și continuă cu referința clientului servește firesc interogărilor care restrâng ambele valori. O interogare care folosește doar referința clientului are o altă problemă de acces. Baza trebuie să găsească înregistrările relevante fără să primească o regiune fixă din interogare.

Documentația PostgreSQL 18 despre indecși compuși, consultată în noiembrie 2026, explică skip scan prin căutări repetate cu condiții de egalitate generate intern. Metoda este în general atractivă când coloana inițială neprecizată are puține valori distincte, astfel încât majoritatea paginilor indexului pot fi omise. Multe valori distincte pot face preferabilă parcurgerea secvențială a tabelului. Este o explicație pentru versiunea documentată, nu un rezultat de performanță al aplicației din luna mai.

Exemplul regiunilor este ipotetic. Dacă sunt puține regiuni, căutarea intervalului relevant în fiecare poate fi utilă. Dacă prima cheie este practic unică pentru fiecare rând, aceeași intuiție devine slabă. Existența unei condiții selective pe o coloană ulterioară nu face irelevant numărul grupurilor precedente.

Chiar și cu o distribuție favorabilă, alt index poate oferi o cale mai ieftină pentru interogarea cea mai importantă. Un index dedicat referinței clientului ar putea evita căutările repetate. Valoarea lui depinde de frecvența interogării, de cerințele de latență și de rândurile sau ordonarea solicitate. Noua cale extinde comparația; nu elimină alternativele.

Istoricul dezvoltării nu este rezultatul aplicației

Dovezile istorice selectate includ și un commit din 4 aprilie care îmbunătățește planificarea parcurgerilor primitive. Acesta ajustează o euristică folosită în skip scan și descrie cazuri în care planificarea contează. Este o îmbunătățire precisă a implementării. Prezentarea lui drept dată a lansării sau drept introducere inițială a întregii funcționalități ar interpreta greșit sursa.

Îmbunătățirea amintește și că o optimizare include decizii de cost dincolo de titlu. Aplicația primește calea aleasă de planificator pentru anumite statistici și condiții ale interogării. Nu primește o promisiune necondiționată că fiecare execuție va evita suficientă muncă. Disponibilitatea generală a unei funcționalități și calitatea planului local cer dovezi separate.

Pentru evaluare, identificați versiunea exactă a bazei și formele interogărilor avute în vedere. Păstrați valori reprezentative ale parametrilor și distribuții reprezentative ale datelor. Compararea unei referințe rare într-un mediu cu una frecventă în alt mediu ar face greu de interpretat decizia despre index. Legați comparația de operațiile pe care serviciul trebuie efectiv să le susțină.

Comparați ansamblul indecșilor

Motivul economic pentru eliminarea unui index cu adevărat redundant depășește durata citirii. Fiecare index păstrat ocupă spațiu și poate adăuga operații de întreținere când datele se schimbă. Sunt motive pentru investigarea consolidării. Nu sunt măsurători ale economiilor aplicației și nu pot compensa o regresie importantă a citirii doar pentru că numărul indecșilor scade.

O verificare propusă ar trebui să compare planurile, comportamentul real la execuție și costurile scrierii pentru configurațiile candidate. Într-un mediu sigur de evaluare, inspectarea planurilor poate arăta dacă este aleasă calea dorită; observațiile de execuție pot verifica apoi dacă apare beneficiul așteptat. Articolul nu a executat niciun experiment cu baza de date și nu oferă măsurători comparative sau un prag procentual recomandat.

Urmăriți și celelalte roluri ale indexului. Acesta poate susține o constrângere, o cerință de ordonare sau altă familie de interogări. Faptul că o căutare poate folosi skip scan nu demonstrează că au fost înlocuite toate responsabilitățile altui index. Numiți rolurile indexului înainte să îl considerați redundant.

Statisticile și cererea aplicației se pot schimba după adoptare. O distribuție cu puține valori inițiale astăzi poate deveni mai puțin favorabilă odată cu dezvoltarea produsului. Decizia de eliminare ar trebui deci să păstreze interogările comparate și semnalul operațional care ar cere reevaluarea. Altfel, echipa păstrează un slogan despre skip scan și pierde motivul pentru care schema ei era acceptabilă.

Indexul dedicat poate rămâne investiția potrivită

Cel mai puternic contraargument la consolidare este o interogare frecventă, sensibilă la latență, pentru care indexul dedicat rămâne previzibil mai ieftin. Plata costurilor de stocare și scriere poate fi rațională. O optimizare a bazei nu creează obligația de a minimiza numărul indecșilor, mai ales când o căutare lentă întârzie o acțiune importantă a clientului.

Folosiți skip scan drept motiv pentru a reexamina presupunerile despre coloanele inițiale. Păstrați indexul existent când rolul măsurat încă îi justifică costurile și eliminați-l doar când ansamblul operațiilor susține alegerea. Într-un proiect de dezvoltare software la comandă, cereți interogările și planurile comparate împreună cu modificarea schemei. Aceste dovezi fac decizia verificabilă când datele sau planificatorul se schimbă din nou.