{"id":144010,"date":"2025-09-25T17:11:55","date_gmt":"2025-09-25T15:11:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/reliz-subd-postgresql-18"},"modified":"2025-09-25T17:11:55","modified_gmt":"2025-09-25T15:11:55","slug":"reliz-subd-postgresql-18","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/reliz-subd-postgresql-18","title":{"rendered":"Emanazione del DBMS PostgreSQL 18","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dopo un anno di sviluppo, \u00e8 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\u00f9 anziana supportata, sar\u00e0 interrotto il 13 novembre. <\/p>\n
Novit\u00e0 principali: <\/p>\n
\n
\u00c8 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\u00f9 processi elaboratori (di default 3), su Linux pu\u00f2 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 \u00e8 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\u00e0 sincrona per soddisfare i requisiti ACID.\n
\u00c8 stata implementata l'ottimizzazione \"skip scan\" negli indici multi-colonna, grazie alla quale l'indice pu\u00f2 essere utilizzato non solo per la verifica della prima colonna indicizzata e per l'intera combinazione 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 verificavano il campo \"status\" o entrambi i campi \"status\" e \"date\"; mentre per le query che controllavano solo il campo \"date\", era necessario eseguire una scansione del contenuto della tabella. La modalit\u00e0 \"skip scan\" consente in determinate situazioni di scansionare l'indice quando si richiede solo il campo \"date\". Questa modalit\u00e0 si applica solo agli indici \"B-tree\" quando si utilizza nel query un operatore condizionale \"=\" sul campo indicizzato, in situazioni in cui il campo non considerato ha un numero ridotto di valori diversi (ad esempio, l'ottimizzazione funziona se il campo dello status \"status\" ha pochi valori fissi diversi).\n
Sono state aggiunte ottimizzazioni che utilizzano pi\u00f9 efficacemente gli indici per query contenenti costrutti \"OR\" e \"IN (...)\" nel blocco \"WHERE\", aumentando anche le prestazioni della pianificazione e dell'esecuzione delle unioni delle tabelle (ad esempio, \u00e8 stato accelerato il codice per la fusione delle hash e consentito l'uso della ordinamento incrementale durante la fusione delle tabelle).\n
\u00c8 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.\n
\u00c8 stata aggiunta la possibilit\u00e0 di creare visualizzazioni materializzate e chiavi per la partizione delle tabelle con indici contrassegnati come \"unique\", che non utilizzano la struttura B-tree.\n
\u00c8 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).\n
Sono state accelerate le operazioni sui testi, come le funzioni per la conversione maiuscole\/minuscole. \u00c8 stata aggiunta la modalit\u00e0 PG_UNICODE_FAST per velocizzare la considerazione delle propriet\u00e0 della locale per i caratteri Unicode.\n
\u00c8 stata implementata la possibilit\u00e0 di salvare le statistiche del pianificatore di query dopo l\u2019aggiornamento tra versioni significative di PostgreSQL. Questa modifica consente di evitare l'esecuzione dell'operazione intensa in termini di risorse \"ANALYZE\" dopo il lancio di una nuova versione, prima della quale si verifica un calo delle prestazioni del DBMS.\n
\u00c8 stata migliorata la performance dell'utilit\u00e0 pg_upgrade, utilizzata per automatizzare la transizione a una nuova versione significativa di PostgreSQL. Le ottimizzazioni sono particolarmente evidenti durante l'aggiornamento di database contenenti un numero elevato di oggetti, come tabelle e sequenze. Per accelerare le operazioni, \u00e8 stato aggiunto il flag «—jobs N» per parallelizzare i controlli in N thread e il flag «—swap» per sostituire interamente le directory contenenti i dati senza l'uso di collegamenti, clonazioni o copie di file.\n
\u00c8 stato aggiunto il supporto per colonne generate virtualmente, il cui valore viene calcolato al volo durante l'esecuzione delle query, senza essere salvato su disco. Se nell'espressione «CREATE TABLE…» per le colonne generate \u00e8 specificata solo la parola chiave «GENERATED» senza una specificazione del tipo (STORED o VIRTUAL), allora la nuova variante viene applicata per impostazione predefinita anzich\u00e9 la vecchia implementazione. Nella vecchia implementazione, i valori venivano generati durante le operazioni «INSERT» o «UPDATE» e salvati su disco per utilizzi successivi. Lo svantaggio delle colonne generate virtualmente \u00e8 che non possono essere utilizzate negli indici, mentre il pregio \u00e8 la possibilit\u00e0 di eseguire normalizzazione e modifica dei dati al volo (rilevante quando si lavora con dati JSON). Per quanto riguarda le colonne generate classiche memorizzate, nel nuovo rilascio \u00e8 stato garantito il supporto per la replica logica.\n
Nei comandi INSERT, UPDATE, DELETE e MERGE \u00e8 stata implementata la possibilit\u00e0 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.*.».\n
\u00c8 stata aggiunta la funzione uuidv7() per generare identificatori univoci casuali nel formato UUIDv7. A differenza della vecchia funzione per la generazione di UUID (gen_random_uuid), che ora \u00e8 ulteriormente disponibile con il nome uuidv4(), nel UUIDv7 viene incluso, oltre al valore casuale, anche il tempo di generazione. La presenza di parti ordinate nel valore UUID (i primi 12 caratteri — tempo epocale, e i successivi 18 — valore casuale) migliora l'efficienza di ordinamento e indicizzazione, il che \u00e8 rilevante poich\u00e9 gli UUID vengono generalmente utilizzati come chiavi primarie (ad esempio, le chiavi create in tempi ravvicinati sono posizionate una accanto all'altra nell'indice).\n
Nell'operazione «LIKE» \u00e8 stata implementata la supporto per il confronto con testi che utilizzano propriet\u00e0 di ordinamento locali «collation», consentendo confronti che tengono conto del significato dei caratteri (ad esempio, durante il confronto pu\u00f2 non essere preso in considerazione il segno dell'accento). \u00c8 stata aggiunta la funzione CASEFOLD per modificare il caso dei caratteri tenendo conto delle propriet\u00e0 di ordinamento locale «collation» (ad esempio, alcuni caratteri hanno pi\u00f9 di due varianti minuscole o richiedono una trasformazione in maiuscolo, anzich\u00e9 in minuscolo, durante il confronto).\n
\u00c8 stata aggiunta la possibilit\u00e0 di utilizzare vincoli temporali (temporal constraint). Nei valori «PRIMARY KEY» e «UNIQUE» per aggiungere vincoli temporali, si dovrebbe utilizzare l'espressione «WITHOUT OVERLAPS», e nel valore «FOREIGN KEY» \u2014 l'espressione PERIOD. Ad esempio, durante la definizione delle chiavi primarie \u00e8 possibile limitare le chiavi con intervalli temporali sovrapposti.\n
\u00c8 stato aggiunto il comando «CREATE FOREIGN TABLE … LIKE command» per creare uno schema di tabella esterna basato sulla definizione di una tabella locale.\n
\u00c8 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\u00e0 come l'autenticazione a due fattori e il single sign-on (SSO).\n
\u00c8 stata aggiunta la funzione ssl_tls13_ciphers(), tramite la quale \u00e8 possibile definire l'elenco degli algoritmi di crittografia consentiti per la connessione utilizzando il protocollo TLSv1.3.\n
Il supporto per l'autenticazione utilizzando l'algoritmo md5 per l'hashing delle password \u00e8 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.\n
Durante l'esecuzione dell'operazione «EXPLAIN ANALYZE» \u00e8 garantita l'uscita di informazioni sul numero di operazioni di ricerca negli indici durante la scansione dell'indice e il numero di accessi ai buffer durante l'esecuzione della query. Nel risultato di «EXPLAIN ANALYZE VERBOSE» sono incluse statistiche su CPU, WAL log e intensit\u00e0 delle operazioni di lettura. Nella tabella pg_stat_all_tables sono state aggiunte informazioni sul tempo speso per l'operazione VACUUM e l'analisi delle tabelle. \u00c8 fornita statistica sull'intensit\u00e0 delle operazioni di input\/output e sul carico del WAL log in relazione a singole connessioni. In pg_stat_subscription_stats e nei log, \u00e8 stata aggiunta informazione con diagnostica sui conflitti durante l'esecuzione delle operazioni di scrittura durante la replica logica.\n
Nelle nuove installazioni \u00e8 abilitato per impostazione predefinita l'uso di checksum per verificare l'integrit\u00e0 dei dati memorizzati. Per annullare questo comportamento durante l'avvio di initdb, \u00e8 necessario specificare l'opzione «—no-data-checksums».\n
Nell'utilit\u00e0 pg_createsubscriber \u00e8 stato aggiunto il flag «—all» per creare repliche logiche in un'unica operazione per tutti i database.\n
\u00c8 stata implementata una nuova versione (3.2) del protocollo utilizzato per l'interazione delle utilit\u00e0 esterne con il DBMS, realizzato nella libreria libpq. L'ultimo aggiornamento del protocollo \u00e8 stato effettuato in PostgreSQL 7.4 (2003). Nella libreria libpq continua a essere utilizzata la versione 3.0 di default. <\/ul>\n