{"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\/es\/blog\/news\/reliz-subd-postgresql-18","title":{"rendered":"Lanzamiento de la base de datos PostgreSQL 18.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Despu\u00e9s de un a\u00f1o de desarrollo, se ha publicado una nueva rama estable de la base de datos PostgreSQL 18. Las actualizaciones para esta nueva rama se lanzar\u00e1n durante cinco a\u00f1os hasta noviembre de 2030. El soporte para PostgreSQL 13.x, la rama m\u00e1s antigua que se sigue apoyando, finalizar\u00e1 el 13 de noviembre. <\/p>\n
Novedades principales: <\/p>\n
\n
Se ha a\u00f1adido un subsistema de entrada\/salida as\u00edncrono que permite aumentar la capacidad de entrada\/salida y eliminar latencias. Adem\u00e1s de la implementaci\u00f3n universal de AIO (io_method=worker) disponible en todas las plataformas, que se basa en la ejecuci\u00f3n de m\u00faltiples procesos manejadores (por defecto 3), en Linux se puede utilizar la interfaz de entrada\/salida as\u00edncrona io_uring (io_method=io_uring), que est\u00e1 soportada desde el n\u00facleo de Linux 5.1. La entrada\/salida as\u00edncrona se utiliza actualmente solo para acelerar la ejecuci\u00f3n de algunas operaciones relacionadas con la lectura de datos del sistema de archivos, como la iteraci\u00f3n secuencial, el escaneo de mapas de \u00edndices y la limpieza (vacuum). En algunas pruebas, el uso de AIO ha llevado a un aumento de rendimiento de 2 a 3 veces. Las operaciones de escritura siguen realiz\u00e1ndose de manera sincr\u00f3nica para cumplir con los requisitos ACID.\n
Se ha implementado la optimizaci\u00f3n 'skip scan' en \u00edndices de m\u00faltiples columnas, lo que permite que el \u00edndice se utilice no solo para verificar la primera columna indexada y la combinaci\u00f3n completa de columnas, sino tambi\u00e9n para procesar por separado las dem\u00e1s columnas indexadas. Por ejemplo, anteriormente, al crear un \u00edndice B-tree sobre las columnas '(status, date)', el \u00edndice solo se aplicaba a consultas que verificaban el campo 'status' o ambos campos 'status' y 'date', mientras que en el caso de una consulta que solo verificaba el campo 'date', se realizaba un escaneo del contenido de la tabla. El modo 'skip scan' permite en ciertas situaciones escanear el \u00edndice al consultar solo el campo 'date'. Este modo se aplica \u00fanicamente a \u00edndices 'B-tree' cuando se utiliza en la consulta un operador condicional '=' sobre el campo indexado, en situaciones donde el campo omitido tiene un n\u00famero peque\u00f1o de valores diferentes (por ejemplo, la optimizaci\u00f3n funcionar\u00e1 si el campo 'status' tiene varios valores fijos).\n
Se han a\u00f1adido optimizaciones que utilizan m\u00e1s eficazmente los \u00edndices para consultas que contienen construcciones 'OR' e 'IN (...)' en el bloque 'WHERE', as\u00ed como que mejoran el rendimiento de planificaci\u00f3n y ejecuci\u00f3n de uniones de tablas (por ejemplo, se ha acelerado el c\u00f3digo de fusi\u00f3n de hashes y se ha permitido el uso de ordenamiento incremental durante la fusi\u00f3n de tablas).\n
Se ha a\u00f1adido soporte para la paralelizaci\u00f3n de la construcci\u00f3n de \u00edndices GIN (\u00cdndice Invertido Generalizado), que se utilizan para indexar valores compuestos, como arreglos, y para organizar la b\u00fasqueda en datos de texto completo o en estructuras JSON.\n
Se ha a\u00f1adido la posibilidad de crear vistas materializadas y claves para seccionar tablas con \u00edndices de la caracter\u00edstica 'unique', que no utilizan la estructura B-tree.\n
Se ha mejorado el rendimiento general de los bloqueos para consultas que interact\u00faan con un gran n\u00famero de tablas, as\u00ed como se han implementado mejoras en el procesamiento de consultas a tablas particionadas, haciendo que el filtrado de secciones no utilizadas y las operaciones de uni\u00f3n (JOIN) sean m\u00e1s r\u00e1pidas.\n
Se han acelerado las operaciones con texto, como las funciones que cambian a may\u00fasculas\/min\u00fasculas. Se ha a\u00f1adido el modo PG_UNICODE_FAST para acelerar el manejo de las propiedades de la localizaci\u00f3n de caracteres Unicode.\n
Se ha implementado la capacidad de guardar estad\u00edsticas del planificador de consultas despu\u00e9s de una actualizaci\u00f3n entre versiones significativas de PostgreSQL. Este cambio permite evitar la ejecuci\u00f3n de la operaci\u00f3n intensiva en recursos 'ANALYZE' despu\u00e9s de iniciar una nueva versi\u00f3n, antes de la cual se observa una disminuci\u00f3n en el rendimiento de la base de datos.\n
Se ha mejorado el rendimiento de la herramienta pg_upgrade, utilizada para automatizar la transici\u00f3n a una nueva versi\u00f3n importante de PostgreSQL. Las optimizaciones son especialmente notables al actualizar bases de datos que contienen un gran n\u00famero de objetos, como tablas y secuencias. Para acelerar el trabajo de pg_upgrade, tambi\u00e9n se ha a\u00f1adido la opci\u00f3n '--jobs N' para paralelizar las verificaciones en N hilos y la opci\u00f3n '--swap' para reemplazar directorios de datos completos sin crear enlaces, sin clonaci\u00f3n y sin copiar archivos.\n
Se ha a\u00f1adido soporte para columnas generadas virtualmente, cuyos valores se eval\u00faan sobre la marcha durante la ejecuci\u00f3n de las consultas, sin guardarse en disco. Si en la expresi\u00f3n 'CREATE TABLE...' para columnas generadas solo se indica la palabra clave 'GENERATED' sin especificar el tipo (STORED o VIRTUAL), la nueva versi\u00f3n se aplica por defecto en lugar de la implementaci\u00f3n anterior. En la implementaci\u00f3n anterior, los valores se generaban durante las operaciones 'INSERT' o 'UPDATE' y se guardaban en disco para su uso posterior. La desventaja de las columnas generadas virtualmente es que no se pueden utilizar en \u00edndices, mientras que su ventaja es que permiten hacer normalizaci\u00f3n y modificaci\u00f3n de datos sobre la marcha (lo cual es relevante al trabajar con datos JSON). En cuanto a las cl\u00e1sicas columnas generadas almacenadas, la nueva versi\u00f3n proporciona soporte para la replicaci\u00f3n l\u00f3gica.\n
En los comandos INSERT, UPDATE, DELETE y MERGE se ha implementado la capacidad de devolver los valores anteriores (OLD) y actuales (CURRENT) en la expresi\u00f3n RETURNING. Por ejemplo, 'UPDATE... RETURNING WITH (OLD AS o, NEW AS n) o.*, n.*.'\n
Se ha a\u00f1adido la funci\u00f3n uuidv7() para generar identificadores \u00fanicos aleatorios en formato UUIDv7. A diferencia de la antigua funci\u00f3n para generar UUID (gen_random_uuid), que ahora tambi\u00e9n est\u00e1 disponible bajo el nombre uuidv4(), en UUIDv7 adem\u00e1s del valor aleatorio se incluye el tiempo de generaci\u00f3n. La presencia de partes ordenadas en el valor UUID (los primeros 12 caracteres son el tiempo de \u00e9poca, y los siguientes 18 son un valor aleatorio) mejora la eficiencia de clasificaci\u00f3n e indexaci\u00f3n, lo que es relevante ya que los UUID generalmente se utilizan para claves primarias (por ejemplo, claves generadas en tiempos cercanos se colocan juntas en el \u00edndice).\n
En la operaci\u00f3n «LIKE» se ha implementado soporte para coincidencias de texto que utilizan propiedades de localizaci\u00f3n no determin\u00edsticas «collation», lo que permite realizar comparaciones teniendo en cuenta el significado de los caracteres (por ejemplo, en la comparaci\u00f3n puede no tenerse en cuenta el acento). Se ha a\u00f1adido la funci\u00f3n CASEFOLD para cambiar la capitalizaci\u00f3n de los caracteres considerando las propiedades de localizaci\u00f3n «collation» (por ejemplo, algunos caracteres tienen m\u00e1s de dos variantes en min\u00fasculas o, al comparar, requieren convertirse a may\u00fasculas en lugar de min\u00fasculas).\n
Se ha a\u00f1adido la posibilidad de utilizar restricciones temporales (temporal constraint). En los valores «PRIMARY KEY» y «UNIQUE» para a\u00f1adir restricciones temporales, se debe usar la expresi\u00f3n «WITHOUT OVERLAPS», y en el valor «FOREIGN KEY» \u2014 la expresi\u00f3n PERIOD. Por ejemplo, al definir claves primarias, se pueden restringir las claves con intervalos de tiempo superpuestos.\n
Se ha a\u00f1adido el comando «CREATE FOREIGN TABLE … LIKE command» para crear un esquema de tabla externa basado en la definici\u00f3n de una tabla local.\n
Se ha a\u00f1adido soporte para conectarse a bases de datos utilizando autenticaci\u00f3n basada en OAUTH 2.0 con el uso de tokens de acceso en lugar de contrase\u00f1as. El uso de OAUTH permite no almacenar contrase\u00f1as en la base de datos, identificar a los usuarios a trav\u00e9s de servicios externos y aprovechar capacidades como la autenticaci\u00f3n de dos factores y el inicio de sesi\u00f3n \u00fanico (SSO).\n
Se ha a\u00f1adido la funci\u00f3n ssl_tls13_ciphers(), que permite determinar la lista de algoritmos de cifrado permitidos al conectar utilizando el protocolo TLSv1.3.\n
Se ha clasificado como obsoleto y se planea eliminar el soporte para autenticaci\u00f3n utilizando el algoritmo md5 para el hash de contrase\u00f1as. En lugar de md5, se recomienda usar el algoritmo SCRAM (SCRAM-SHA-256), que apareci\u00f3 en PostgreSQL 10. Adem\u00e1s, se destaca la implementaci\u00f3n del soporte para el paso de autenticaci\u00f3n basado en SCRAM al conectarse a servidores PostgreSQL externos a trav\u00e9s de postgres_fdw y dblink.\n
Al ejecutar la operaci\u00f3n «EXPLAIN ANALYZE» se proporciona informaci\u00f3n sobre el n\u00famero de operaciones de b\u00fasqueda en \u00edndices al escanear el \u00edndice y el n\u00famero de accesos a los b\u00faferes al ejecutar la consulta. En la salida de «EXPLAIN ANALYZE VERBOSE» se incluye estad\u00edsticas sobre la CPU, el registro WAL y la intensidad de las operaciones de lectura. A la tabla pg_stat_all_tables se han a\u00f1adido datos sobre el tiempo gastado en la operaci\u00f3n VACUUM y el an\u00e1lisis de tablas. Se ha proporcionado estad\u00edsticas sobre la intensidad de entrada\/salida y la carga en el registro WAL por conexi\u00f3n. Se ha a\u00f1adido informaci\u00f3n con el diagn\u00f3stico de conflictos durante las operaciones de escritura en los registros de pg_stat_subscription_stats y en los logs durante la replicaci\u00f3n l\u00f3gica.\n
En las nuevas instalaciones, el uso de sumas de verificaci\u00f3n para comprobar la integridad de los datos almacenados est\u00e1 habilitado por defecto. Para desactivar este comportamiento al iniciar initdb, se debe especificar la opci\u00f3n «—no-data-checksums».\n
Se ha a\u00f1adido la bandera «—all» a la utilidad pg_createsubscriber para crear r\u00e9plicas l\u00f3gicas con un solo comando para todas las bases de datos.\n
Se ha implementado una nueva versi\u00f3n (3.2) del protocolo utilizado para la interacci\u00f3n de herramientas externas con el SGBD, que se ha implementado en la biblioteca libpq. La \u00faltima actualizaci\u00f3n del protocolo se realiz\u00f3 en PostgreSQL 7.4 (a\u00f1o 2003). En la biblioteca libpq, por defecto, se sigue utilizando la versi\u00f3n 3.0. <\/ul>\n