A PostgreSQL 18 adatbázis-kezelő rendszer kiadása

Az új stabil PostgreSQL 18 adatbázis-kezelő rendszer kiadása egy év fejlesztés után. Az új ágra vonatkozó frissítések 2030 novemberéig, öt éven át érkeznek. A PostgreSQL 13.x, a legöregebb támogatott ág, támogatása 2023. november 13-án megszűnik.

Főbb újítások:

• Bevezetésre került az aszinkron bemenet/kimenet alrendszere, amely lehetővé teszi a bemenet/kimenet teljesítményének növelését és a késleltetések megszüntetését. Az összes platformon elérhető univerzális AIO implementáció mellett (io_method=worker), amely három feldolgozási folyamaton alapul, Linux alatt használható az io_uring aszinkron bemenet/kimenet interfész (io_method=io_uring), amelyet a Linux 5.1 kernel óta támogatnak. Az aszinkron bemenet/kimenet egyelőre csak a fájlrendszerből történő adatolvasással kapcsolatos műveletek gyorsítására van használva, mint például a soros átvizsgálás, az indexelt bitet térkép szkennelése és a takarítás (vacuum). Egyes tesztek szerint az AIO használata 2-3-szoros teljesítménynövekedést eredményez. Az írási műveletek továbbra is szinkron módon zajlanak az ACID követelmények teljesítése érdekében.
• Megvalósításra került a »skip scan« optimalizálás a többoszlopos indexeknél, amely lehetővé teszi, hogy az index ne csak az első indexelt oszlop ellenőrzésére és a teljes oszlopkötésre, hanem a többi indexelt oszlop egyéni feldolgozására is szolgáljon. Például korábban a »(status, date)« oszlopokon létrehozott B-tree index csak akkor alkalmazható, ha a lekérdezés az „status” mezőt vagy mindkét mezőt, az „status” és a „date”-t ellenőrzi, egyedüli „date” mező vizsgálatakor a táblázat tartalmának átvizsgálására került sor. A »skip scan« mód lehetővé teszi bizonyos helyzetekben az index szkennelését, ha csak a „date” mezőt kérdezik le. A mód kizárólag a »B-tree« indexeknél alkalmazható, ha a lekérdezés feltételes operátora „=” az indexelt mezőn van, olyan helyzetekben, amikor a kihagyott mező eltérő értékeinek száma csekély (például az optimalizálás működni fog, ha a „status” mezőnek néhány rögzített értéke van).
• Optimalizálások kerültek bevezetésre, amelyek hatékonyabban használják az indexeket az „OR” és „IN (…)” kifejezéseket tartalmazó lekérdezések esetén a „WHERE” blokkban, és javítják a táblák egyesítésének tervezési és végrehajtási teljesítményét (például felgyorsult a hash-mészárlás kódja, és engedélyezett az inkrementális rendezés táblák egyesítésekor).
• Támogatás került hozzáadásra a GIN (Generalized Inverted Index) indexek párhuzamos építéséhez, amelyeket összetett értékek, például tömbök indexelésére és teljes szöveg keresésének vagy JSON struktúráknak a keresésére használnak.
• Lehetőség került bevezetésre anyagolt nézetek és kulcsok létrehozására a szekcionált táblák számára egyedi, B-fába nem illeszkedő indexekkel.
• Növelték a zárolások általános teljesítményét olyan lekérdezések esetén, amelyek nagy számú táblával dolgoznak, és javításokat hajtottak végre a szekcionált táblák lekérdezéseinek feldolgozásában, amelyek felgyorsítják a fel nem használt szekciók kiszűrését és az egyesítési műveleteket (JOIN).
• Felgyorsultak a szöveggel végzett műveletek, például a kis- és nagybetűs átkonvertáló funkciók. Bevezetésre került a PG_UNICODE_FAST mód a Unicode karakterek helyi tulajdonságainak figyelembevételéhez.
• Lehetőség került bevezetésre a lekérdezés ütemező statisztikáinak megőrzésére a fontos frissítések közötti frissítések után PostgreSQL-ben. A változtatás lehetővé teszi a „ANALYZE” erőforrás-igényes művelet végrehajtásának elkerülését az új verzió indítása után, amely előtt a DBMS teljesítménye csökken.
• Növelve lett a pg_upgrade eszköz teljesítménye, amelyet a PostgreSQL új jelentős kiadásra való áttérés automatizálására használnak. Az optimalizálások különösen észlelhetők a nagy számú objektumot, például táblákat és sorozatokat tartalmazó adatbázisok frissítésekor. A pg_upgrade munkájának felgyorsításához bevezetésre került a „—jobs N” jelző a N szálban történő ellenőrzések párhuzamosítására, valamint a „—swap” jelző az adatmappák teljes cseréjére hivatkozások felállítása nélkül, klónozás és fájlok másolása nélkül.
• Hozzáadva a virtuális generált oszlopok támogatása, amelyek értéke azonnal kiszámításra kerül a lekérdezések futása közben anélkül, hogy lemezre kellene tárolni. Ha a 'CREATE TABLE...' kifejezésben a generált oszlopokhoz csak a 'GENERATED' kulcsszó van megadva, típus (STORED vagy VIRTUAL) pontosítása nélkül, akkor az új változat alapértelmezettként alkalmazásra kerül a régi megvalósítás helyett. A régi megvalósítás során az értékek az 'INSERT' vagy 'UPDATE' műveletek végrehajtása közben generálódtak, és lemezre lettek tárolva későbbi felhasználás céljából. A virtuális generált oszlopok hátránya, hogy nem lehet őket indexekben használni, előnyük viszont, hogy lehetővé teszik az adatok azonnali normalizálását és módosítását (ami releváns a JSON adatokkal való munka során). A klasszikus tárolt generált oszlopok esetén az új verzió támogatja a logikai replikációt.
• Az INSERT, UPDATE, DELETE és MERGE utasításokban megvalósult a múltbeli (OLD) és aktuális (CURRENT) értékek kimenetének lehetősége a RETURNING kifejezésben. Például: 'UPDATE... RETURNING WITH (OLD AS o, NEW AS n) o.*, n.*.'
• Hozzáadva a uuidv7() függvény, amely véletlenszerű egyedi azonosítók generálására szolgál UUIDv7 formátumban. Ellentétben a régi UUID-generáló függvénnyel (gen_random_uuid), amely mostantól az uuidv4() néven is elérhető, az UUIDv7-be időbeli generálás is belekerül a véletlenszerű érték mellett. Az UUID értékének rendezett részei (az első 12 karakter az epoch idő, a következő 18 pedig egy véletlenszerű érték) növelik a rendezés és indexelés hatékonyságát, ami releváns, mivel az UUID-kat általában elsődleges kulcsokhoz használják (például az egymáshoz közeli időben létrehozott kulcsok egymás mellett helyezkednek el az indexben).
• A 'LIKE' műveletben megvalósult a text alapú összehasonlítások támogatása, amelyek során nem determinisztikus lokalizációs 'collation' tulajdonságok használnak, lehetővé téve a karakterek jelentése szerinti párhuzamosításokat (például az összehasonlítás során figyelmen kívül hagyható a hangsúlyjel). Hozzáadva a CASEFOLD függvény a karakterek kis- és nagybetűs módosítására a 'collation' lokalizációs tulajdonságainak figyelembevételével (például egyes karaktereknek több mint két kisbetűs változata van, vagy az összehasonlítás során nagybetűsre kell átkonvertálni, nem kisbetűsre).
• Bevezetésre került az időkorlátok (temporal constraint) használatának lehetősége. A "PRIMARY KEY" és "UNIQUE" értékek esetén az időkorlátok hozzáadásához a "WITHOUT OVERLAPS" kifejezést kell használni, míg a "FOREIGN KEY" értéknél a PERIOD kifejezést. Például a primer kulcsok meghatározásakor korlátozhatók az átfedésben lévő időintervallumú kulcsok.
• Bevezetésre került a "CREATE FOREIGN TABLE … LIKE command" parancs külső táblák sémájának létrehozására a helyi tábla meghatározása alapján.
• Támogatás került a DBMS-hez való csatlakozásra OAUTH 2.0 alapú hitelesítéssel, hozzáférési token használatával a jelszó helyett. Az OAUTH alkalmazása lehetővé teszi a jelszavak adatbázisban való tárolásának elkerülését, továbbá a felhasználók külső szolgáltatásokon keresztül történő azonosítását, valamint olyan lehetőségek használatát, mint a kétfaktoros hitelesítés és az egységes bejelentkezési pont (SSO).
• Bevezetésre került az ssl_tls13_ciphers() függvény, amelyen keresztül meghatározható a TLSv1.3 protokollal való csatlakozáskor engedélyezett titkosítási algoritmusok listája.
• Az MD5 algoritmus használatával történő jelszóhashek hitelesítésének támogatása réginek és eltávolításra tervezettnek minősült. Az MD5 helyett ajánlott a SCRAM (SCRAM-SHA-256) algoritmus alkalmazása, amely a PostgreSQL 10-ben jelent meg. Továbbá megjegyzendő a SCRAM-alapú hitelesítés átjárásának támogatása a postgres_fdw és dblink révén külső PostgreSQL szerverekhez való csatlakozáskor.
• Az "EXPLAIN ANALYZE" művelet végrehajtása során információk kerültek megjelenítésre az indexek keresési műveleteinek számáról és a lekérdezés végrehajtása során a pufferekhez való hozzáférések számáról. Az "EXPLAIN ANALYZE VERBOSE" kimenetébe bekerült a CPU-ról, WAL naplóról és az olvasási műveletek intenzitásáról szóló statisztika. A pg_stat_all_tables táblához hozzáadódott az idő, amelyet a VACUUM művelet és a táblák elemzése során töltöttek el. Megtudható a be- és kimeneti intenzitás és a WAL napló terhelése egyes kapcsolatok mentén. A pg_stat_subscription_stats és a naplók tartalmaznak információt a konzisztencia problémákról, amelyek írási műveletek végrehajtása során lépnek fel logikai replikációnál.
• Az új telepítéseknél alapértelmezés szerint engedélyezve van az adatok integritásának ellenőrzésére szolgáló ellenőrző összegek használata. Ennek a viselkedésnek a leállításához az initdb indításakor a "—no-data-checksums" opciót kell megadni.
• A pg_createsubscriber segédprogramhoz hozzáadva a "—all" kapcsoló, amely lehetővé teszi logikai replikák létrehozását egy parancs segítségével az összes adatbázis számára.
• Kiadásra került a protokoll új verziója (3.2), amelyet külső segédprogramok és az adatbázis-kezelő közötti kapcsolatra használnak, és amely megvalósításra került a libpq könyvtárban. A protokoll korábbi frissítése a PostgreSQL 7.4 (2003) verzióban történt. A libpq könyvtárban alapértelmezés szerint a 3.0 verziót használják.

Forrás: opennet.ru