{"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\/novosti-interneta\/reliz-subd-postgresql-18","title":{"rendered":"Release 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 database 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 vecchia supportata, terminer\u00e0 il 13 novembre. <\/p>\n
Novit\u00e0 principali: <\/p>\n
\n
\u00c8 stata aggiunta una sottosistema di input\/output asincrono che aumenta la larghezza di banda di input\/output ed elimina i ritardi. Oltre alla generica implementazione AIO (io_method=worker) disponibile su tutte le piattaforme, basata sull'esecuzione di pi\u00f9 processi handler (3 per impostazione predefinita), in 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 velocizzare l'esecuzione di alcune operazioni di lettura dei dati dal filesystem, come l'iterazione sequenziale, la scansione della mappa degli indici e le operazioni di pulizia (vacuum). In alcuni test, l'uso di AIO porta a un aumento delle prestazioni da 2 a 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 multicolonna, permettendo all'indice di essere utilizzato non solo per controllare la prima colonna indicizzata e l'intero insieme di colonne, ma anche per elaborare separatamente le altre colonne indicizzate. Ad esempio, in precedenza, creando 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 effettuata una scansione del contenuto della tabella. La modalit\u00e0 'skip scan' consente, in determinate situazioni, di scansionare l'indice per la query che controlla solo il campo 'date'. Questa modalit\u00e0 si applica solo agli indici 'B-tree' utilizzati in una query con l'operatore condizionale '=' su un campo indicizzato, in situazioni in cui il campo trascurato ha un numero ridotto di valori distinti (ad esempio, l'ottimizzazione funzioner\u00e0 se il campo status 'status' ha pochi valori fissi).\n
Sono state aggiunte ottimizzazioni che utilizzano in modo pi\u00f9 efficace gli indici per le query contenenti le costruzioni 'OR' e 'IN (...)' nel blocco 'WHERE', migliorando anche le prestazioni della pianificazione e dell'esecuzione delle unioni di tabelle (ad esempio, \u00e8 stato velocizzato il codice di unione degli hash ed \u00e8 stato consentito l'uso dell'ordinamento incrementale durante l'unione delle tabelle).\n
\u00c8 stato aggiunto il supporto per il parallelismo nella creazione di indici GIN (Generalized Inverted Index), utilizzati per indicizzare valori complessi, come array, e per organizzare la ricerca nei dati di testo completo o nelle strutture JSON.\n
\u00c8 stata aggiunta la possibilit\u00e0 di creare viste materializzate e chiavi per la partizionatura delle tabelle con indici marcati come 'unique', che non utilizzano la struttura B-tree.\n
\u00c8 stata migliorata l'efficienza complessiva dei lock per le query che operano su un gran numero di tabelle, sono stati effettuati miglioramenti anche nella gestione delle query su tabelle partizionate, accelerando il filtraggio delle sezioni non utilizzate e le operazioni di join.\n
\u00c8 stato accelerato il trattamento del testo, come le funzioni di conversione in maiuscolo\/minuscolo. \u00c8 stata aggiunta la modalit\u00e0 PG_UNICODE_FAST per velocizzare la gestione delle propriet\u00e0 dei caratteri Unicode.\n
\u00c8 stata implementata la possibilit\u00e0 di mantenere le statistiche del pianificatore delle query dopo l'aggiornamento tra le versioni significative di PostgreSQL. Questa modifica permette di evitare l'esecuzione dell'operazione 'ANALYZE', che richiede molte risorse, dopo il lancio di una nuova versione, evitando cos\u00ec un calo delle prestazioni del DBMS fino al completamento dell'operazione.\n
\u00c8 stata migliorata l'efficienza dello strumento pg_upgrade, utilizzato per automatizzare la transizione a una nuova versione significativa di PostgreSQL. Le ottimizzazioni sono particolarmente evidenti nell'aggiornamento di database contenenti un gran numero di oggetti, come tabelle e sequenze. Per accelerare il funzionamento di pg_upgrade \u00e8 stato anche aggiunto il flag '--jobs N' per parallelizzare i controlli in N thread e il flag '--swap' per sostituire intere directory di dati senza creare collegamenti, senza clonare e senza copiare file.\n
\u00c8 stata aggiunta la supporto per colonne generate virtuali, i cui valori vengono calcolati al volo durante l'esecuzione delle query, senza essere salvati su disco. Se nella dichiarazione 'CREATE TABLE...' per colonne generate \u00e8 specificata solo la parola chiave 'GENERATED' senza indicazione del tipo (STORED o VIRTUAL), viene applicata la nuova variante per default invece della vecchia implementazione. Nella vecchia implementazione, i valori venivano generati durante le operazioni 'INSERT' o 'UPDATE' e salvati su disco per un uso successivo. Lo svantaggio delle colonne generate virtuali \u00e8 l'impossibilit\u00e0 di utilizzarle negli indici, mentre il vantaggio \u00e8 la capacit\u00e0 di normalizzare e modificare i dati al volo (particolarmente rilevante quando si lavora con dati JSON). Per quanto riguarda le colonne generate classiche, nel nuovo rilascio \u00e8 stata assicurata la supporto per la replica logica.\n
Nelle istruzioni INSERT, UPDATE, DELETE e MERGE \u00e8 stata implementata la possibilit\u00e0 di visualizzare i valori precedenti (OLD) e correnti (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 la generazione di identificatori unici casuali nel formato UUIDv7. A differenza della vecchia funzione per la generazione di UUID (gen_random_uuid), ora ulteriormente disponibile con il nome uuidv4(), in UUIDv7 oltre al valore casuale \u00e8 incluso il tempo di generazione. La presenza di parti ordinate nel valore UUID (i primi 12 caratteri - tempo epocale, e i successivi 18 - valore casuale) aumenta l'efficienza di ordinamento e indicizzazione, poich\u00e9 gli UUID vengono generalmente utilizzati per le chiavi primarie (ad esempio, le chiavi create in un breve intervallo di tempo sono raggruppate vicine tra loro nell'indice).\n
Nell'operazione «LIKE» \u00e8 stata implementata la supporto per le corrispondenze testuali utilizzando propriet\u00e0 di collazione non determinate, che consentono confronti che tengono conto del significato dei caratteri (ad esempio, durante il confronto potrebbe non essere considerato l'accento). \u00c8 stata aggiunta la funzione CASEFOLD per modificare la registrazione dei caratteri in base alle propriet\u00e0 di collazione, (ad esempio, alcuni caratteri hanno pi\u00f9 di due varianti minuscole o richiedono una conversione 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 deve utilizzare l'espressione «WITHOUT OVERLAPS», mentre per il valore «FOREIGN KEY» \u2014 l'espressione PERIOD. Ad esempio, durante la definizione delle chiavi primarie \u00e8 possibile limitare le chiavi con intervalli di tempo 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 stato aggiunto il supporto per la connessione ai DBMS utilizzando l'autenticazione basata su OAUTH 2.0 utilizzando un token di accesso al posto della password. L'uso di OAUTH consente di non memorizzare le password nei DB, identificando gli utenti attraverso servizi esterni e sfruttando funzionalit\u00e0 come l'autenticazione a due fattori e il single sign-on (SSO).\n
\u00c8 stata aggiunta la funzione ssl_tls13_ciphers(), attraverso la quale \u00e8 possibile determinare l'elenco degli algoritmi di crittografia consentiti durante la connessione utilizzando il protocollo TLSv1.3.\n
La supporto per l'autenticazione utilizzando l'algoritmo md5 per l'hashing delle password \u00e8 stata trasferita nella categoria delle funzionalit\u00e0 obsolete e pianificate per la rimozione. Si raccomanda di utilizzare l'algoritmo SCRAM (SCRAM-SHA-256), introdotto in PostgreSQL 10. Inoltre, \u00e8 stata implementata la possibilit\u00e0 di passare l'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» viene fornita l'uscita delle 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. Nell'uscita «EXPLAIN ANALYZE VERBOSE» \u00e8 stata inclusa la statistica su CPU, WAL e intensit\u00e0 delle operazioni di lettura. Nella tabella pg_stat_all_tables sono state aggiunte informazioni sul tempo speso per le operazioni VACUUM e l'analisi delle tabelle. \u00c8 stata fornita statistica sull'intensit\u00e0 di I\/O e sul carico del WAL a livello di singole connessioni. In pg_stat_subscription_stats e nei log \u00e8 stata aggiunta informazione diagnostica sui conflitti durante le operazioni di scrittura durante la replicazione logica.\n
Nelle nuove installazioni \u00e8 abilitato per impostazione predefinita l'uso delle somme di controllo 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'utility pg_createsubscriber \u00e8 stato aggiunto il flag «—all» per creare repliche logiche con un singolo comando per tutti i database.\n
\u00c8 stata implementata una nuova versione (3.2) del protocollo utilizzato per l'interazione delle utility esterne con il DBMS, realizzata nella libreria libpq. L'ultima aggiornamento del protocollo \u00e8 avvenuto in PostgreSQL 7.4 (2003). Nella libreria libpq continua a essere utilizzata per impostazione predefinita la versione 3.0. <\/ul>\n