Emanazione del DBMS PostgreSQL 18

Dopo un anno di sviluppo, è stata pubblicata una nuova versione stabile del DBMS PostgreSQL 18. Gli aggiornamenti per questa nuova versione saranno rilasciati per cinque anni, fino a novembre 2030. Il supporto per PostgreSQL 13.x, la versione più anziana supportata, sarà interrotto il 13 novembre.

Novità principali:

• È stata aggiunta una sottosistema per l'input/output asincrono, che consente di aumentare la larghezza di banda input/output e ridurre i ritardi. Oltre all'implementazione universale di AIO (io_method=worker), disponibile su tutte le piattaforme e basata sull'esecuzione di più processi elaboratori (di default 3), su Linux può essere utilizzata l'interfaccia di input/output asincrono io_uring (io_method=io_uring), supportata a partire dal kernel Linux 5.1. L'input/output asincrono è attualmente attivato solo per accelerare l'esecuzione di alcune operazioni legate alla lettura dei dati dal file system, come la scansione sequenziale, la scansione delle bitmap degli indici e l'esecuzione della pulizia (vacuum). In alcuni test, l'uso di AIO ha portato a un aumento delle prestazioni di 2-3 volte. Le operazioni di scrittura continuano a essere eseguite in modalità sincrona per soddisfare i requisiti ACID.
• È stata implementata l'ottimizzazione 'skip scan' negli indici multicolonna, che consente all'indice di essere utilizzato non solo per controllare la prima colonna indicizzata e la combinazione completa di colonne, ma anche per elaborare separatamente le altre colonne indicizzate. Ad esempio, in precedenza, quando veniva creato un indice B-tree sulle colonne '(status, date)', l'indice veniva applicato solo per le query che controllavano il campo 'status' o entrambi i campi 'status' e 'date', mentre per le query che controllavano solo il campo 'date' veniva eseguita la scansione del contenuto della tabella. La modalità 'skip scan' consente, in determinate situazioni, di scansionare l'indice anche per query sul solo campo 'date'. La modalità è applicabile solo agli indici 'B-tree' quando si utilizza l'operatore condizionale '=' sul campo indicizzato, in situazioni in cui il campo trascurato ha un numero ridotto di valori diversi (ad esempio, l'ottimizzazione funzionerà se il campo 'status' ha pochi valori fissi).
• Sono state aggiunte ottimizzazioni che utilizzano in modo più efficiente gli indici per le query contenenti le istruzioni "OR" e "IN(...)" nel blocco "WHERE", aumentando anche le prestazioni della pianificazione e dell'esecuzione delle join tra tabelle (ad esempio, il codice per il merge degli Hash è stato velocizzato e ora è permittedo l'uso della sort incrementale durante il merge delle tabelle).
• È stato aggiunto il supporto per il parallelismo nella costruzione degli indici GIN (Generalized Inverted Index), utilizzati per indicizzare valori compositi, come array, e per organizzare la ricerca su dati testuali completi o strutture JSON.
• È stata introdotta la possibilità di creare viste materializzate e chiavi per la partizione di tabelle con indici con proprietà "unique" che non utilizzano la struttura B-tree.
• È stata migliorata la performance complessiva dei lock per le query che operano su un numero elevato di tabelle, e sono stati apportati miglioramenti nella gestione delle query su tabelle partizionate, accelerando il filtraggio delle sezioni non utilizzate e le operazioni di merge (JOIN).
• Sono state accelerate le operazioni sui testi, come le funzioni per la conversione maiuscole/minuscole. È stata aggiunta la modalità PG_UNICODE_FAST per velocizzare la considerazione delle proprietà della locale per i caratteri Unicode.
• È stata implementata la possibilità di salvare le statistiche del planner di query dopo l'aggiornamento tra versioni significative di PostgreSQL. Questa modifica consente di evitare l'esecuzione dell'operazione "ANALYZE", che richiede molte risorse, dopo l'avvio di una nuova versione, fino al completamento della quale si osserva un calo delle prestazioni del DBMS.
• È stata migliorata la performance dello strumento pg_upgrade, utilizzato per automatizzare la transizione a una nuova versione significativa di PostgreSQL. Le ottimizzazioni sono particolarmente evidenti durante l'aggiornamento di database contenenti un elevato numero di oggetti, come tabelle e sequenze. Per accelerare il lavoro di pg_upgrade è stato anche aggiunto il flag "--jobs N" per parallelizzare i controlli in N thread e il flag "--swap" per sostituire interamente le directory con i dati senza riferimenti, clonazioni o copie di file.
• È stata aggiunta la supporto per le colonne generate virtualmente, i cui valori vengono calcolati al volo durante l'esecuzione delle query, senza essere salvati su disco. Se nell'espressione «CREATE TABLE…» per le colonne generate viene specificata solo la parola chiave «GENERATED» senza ulteriori dettagli sul tipo (STORED o VIRTUAL), questa nuova modalità si applica per default invece della precedente implementazione. Nella vecchia implementazione, i valori venivano generati durante le operazioni «INSERT» o «UPDATE» e salvati su disco per un uso successivo. Uno svantaggio delle colonne generate virtualmente è l'impossibilità di usarle negli indici, mentre un vantaggio è la possibilità di normalizzare e modificare i dati al volo (particolarmente utile quando si lavora con dati JSON). Per quanto riguarda le classiche colonne generate memorizzate, nella nuova versione è stata introdotta la supporto per la replica logica.
• Nei comandi INSERT, UPDATE, DELETE e MERGE è stata introdotta la possibilità di restituire i valori precedenti (OLD) e attuali (CURRENT) nell'espressione RETURNING. Ad esempio, «UPDATE… RETURNING WITH (OLD AS o, NEW AS n) o.*, n.*.».
• È stata aggiunta la funzione uuidv7() per generare identificatori unici casuali nel formato UUIDv7. A differenza della vecchia funzione per la generazione di UUID (gen_random_uuid), che ora è disponibile anche con il nome uuidv4(), in UUIDv7, oltre al valore casuale, viene incluso il tempo di generazione. La presenza di parti ordinate nel valore UUID (i primi 12 caratteri rappresentano il tempo epocale e i successivi 18 il valore casuale) migliora l'efficienza di ordinamento e indicizzazione, il che è rilevante poiché gli UUID sono comunemente utilizzati per chiavi primarie (ad esempio, le chiavi generate in un tempo ravvicinato vengono collocate vicine l'una all'altra nell'indice).
• Nell'operazione «LIKE» è stata implementata la supporto per confronti testuali che utilizzano proprietà non deterministiche della collation, permettendo di eseguire confronti tenendo conto del significato dei caratteri (ad esempio, durante il confronto potrebbe non essere considerato l'accento). È stata aggiunta la funzione CASEFOLD per cambiare la maiuscole e minuscole dei caratteri tenendo conto delle proprietà della collation (ad esempio, alcuni caratteri hanno più di due varianti minuscole o durante il confronto richiedono una trasformazione in maiuscole, piuttosto che in minuscole).
• È stata aggiunta la possibilità di utilizzare vincoli temporali (temporal constraint). Nei valori "PRIMARY KEY" e "UNIQUE" per l'aggiunta di vincoli temporali, si deve utilizzare l'espressione "WITHOUT OVERLAPS", mentre nel valore "FOREIGN KEY" si deve utilizzare l'espressione PERIOD. Ad esempio, nella definizione delle chiavi primarie è possibile limitare le chiavi con intervalli di tempo sovrapposti.
• È stato aggiunto il comando "CREATE FOREIGN TABLE … LIKE command" per creare uno schema di tabella esterna basato sulla definizione di una tabella locale.
• È stata aggiunta la supporto per la connessione a DBMS utilizzando l'autenticazione basata su OAUTH 2.0 con l'uso di un token di accesso invece della password. L'uso di OAUTH consente di non salvare le password nel DB e di identificare gli utenti tramite servizi esterni, oltre a utilizzare funzionalità come l'autenticazione a due fattori e il single sign-on (SSO).
• È stata aggiunta la funzione ssl_tls13_ciphers(), tramite la quale è possibile definire l'elenco degli algoritmi di crittografia consentiti per la connessione utilizzando il protocollo TLSv1.3.
• Il supporto per l'autenticazione utilizzando l'algoritmo md5 per l'hashing delle password è stato classificato come obsoleto e pianificato per la rimozione. Invece di md5, si consiglia di utilizzare l'algoritmo SCRAM (SCRAM-SHA-256), introdotto in PostgreSQL 10. Inoltre, si segnala l'implementazione del supporto per il pass-through dell'autenticazione basata su SCRAM quando ci si connette tramite postgres_fdw e dblink a server PostgreSQL esterni.
• Durante l'esecuzione dell'operazione "EXPLAIN ANALYZE", sono state fornite informazioni sul numero di operazioni di ricerca negli indici durante la scansione dell'indice e sul numero di accessi ai buffer durante l'esecuzione della query. L'output di "EXPLAIN ANALYZE VERBOSE" include statistiche su CPU, WAL log e intensità delle operazioni di lettura. Nella tabella pg_stat_all_tables sono state aggiunte informazioni sui tempi impiegati per le operazioni VACUUM e analisi delle tabelle. Statistiche sull'intensità di input/output e sul carico del WAL log sono stati forniti per singole connessioni. In pg_stat_subscription_stats e nei log è stata aggiunta un'informazione diagnostica sui conflitti durante l'esecuzione di operazioni di scrittura durante la replicazione logica.
• Nelle nuove installazioni, l'uso delle somme di controllo per la verifica dell'integrità dei dati memorizzati è abilitato di default. Per disattivare questo comportamento durante l'avvio di initdb, è necessario specificare l'opzione "—no-data-checksums".
• Nell'utilità pg_createsubscriber è stato aggiunto il flag «—all» per creare repliche logiche con un solo comando per tutti i database.
• È stata implementata una nuova versione (3.2) del protocollo utilizzato per l'interazione delle utilità esterne con il DBMS, realizzato nella libreria libpq. L'ultimo aggiornamento del protocollo è stato effettuato in PostgreSQL 7.4 (2003). Nella libreria libpq continua a essere utilizzata la versione 3.0 di default.

Fonte: opennet.ru