{"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\/pt\/blog\/news\/reliz-subd-postgresql-18","title":{"rendered":"Lan\u00e7amento do SGBD PostgreSQL 18","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Ap\u00f3s um ano de desenvolvimento, uma nova vers\u00e3o est\u00e1vel do SGBD PostgreSQL 18 foi publicada. As atualiza\u00e7\u00f5es para a nova vers\u00e3o ser\u00e3o lan\u00e7adas durante cinco anos at\u00e9 novembro de 2030. O suporte para o PostgreSQL 13.x, a vers\u00e3o mais antiga suportada, ser\u00e1 encerrado em 13 de novembro. <\/p>\n
Principais novidades: <\/p>\n
\n
Foi adicionada uma subsistema de entrada\/sa\u00edda ass\u00edncrona, permitindo aumentar a capacidade de entrada\/sa\u00edda e eliminar atrasos. Al\u00e9m da implementa\u00e7\u00e3o universal de AIO dispon\u00edvel em todas as plataformas (io_method=worker), baseada na execu\u00e7\u00e3o de v\u00e1rios processos manipuladores (por padr\u00e3o, 3), no Linux pode ser utilizado a interface de entrada\/sa\u00edda ass\u00edncrona io_uring (io_method=io_uring), suportada a partir do n\u00facleo Linux 5.1. O AIO est\u00e1 atualmente ativo apenas para acelerar a execu\u00e7\u00e3o de algumas opera\u00e7\u00f5es relacionadas \u00e0 leitura de dados do sistema de arquivos, como varredura sequencial, varredura de bitmap de \u00edndices e realiza\u00e7\u00e3o de limpeza (vacuum). Em alguns testes, o uso do AIO resulta em um aumento de desempenho de 2 a 3 vezes. As opera\u00e7\u00f5es de grava\u00e7\u00e3o continuam a ser executadas de forma s\u00edncrona para atender aos requisitos ACID.\n
Foi implementada a otimiza\u00e7\u00e3o \u2018skip scan\u2019 em \u00edndices multi-colunas, permitindo que o \u00edndice seja usado n\u00e3o apenas para verificar a primeira coluna indexada e a combina\u00e7\u00e3o completa de colunas, mas tamb\u00e9m para processar separadamente as demais colunas indexadas. Por exemplo, anteriormente, ao criar um \u00edndice B-tree sobre as colunas \u2018(status, date)\u2019, o \u00edndice era aplicado apenas para consultas que verificavam o campo \u2018status\u2019 ou ambos os campos \u2018status\u2019 e \u2018date\u2019. Ao verificar na consulta apenas o campo \u2018date\u2019, era necess\u00e1rio escanear todo o conte\u00fado da tabela. O modo \u2018skip scan\u2019 permite, em certas situa\u00e7\u00f5es, escanear o \u00edndice ao consultar apenas o campo \u2018date\u2019. Este modo \u00e9 aplicado apenas a \u00edndices \u2018B-tree\u2019 quando utilizando o operador condicional \u2018=\u2019 sobre o campo indexado, em situa\u00e7\u00f5es onde o campo ausente tem um pequeno n\u00famero de valores diferentes (por exemplo, a otimiza\u00e7\u00e3o funcionar\u00e1 se o campo status \u2018status\u2019 tiver alguns valores fixos).\n
Foram adicionadas otimiza\u00e7\u00f5es que utilizam os \u00edndices de forma mais eficiente para consultas que cont\u00eam constru\u00e7\u00f5es \u2018OR\u2019 e \u2018IN (...)\u2019 no bloco \u2018WHERE\u2019, al\u00e9m de aumentar o desempenho do planejamento e execu\u00e7\u00e3o de jun\u00e7\u00f5es de tabelas (por exemplo, o c\u00f3digo de uni\u00e3o de hashes foi acelerado e agora \u00e9 permitido usar ordena\u00e7\u00e3o incremental durante a uni\u00e3o de tabelas).\n
Adicionada a suporte para paraleliza\u00e7\u00e3o da constru\u00e7\u00e3o de \u00edndices GIN (\u00cdndice Invertido Generalizado), aplicados \u00e0 indexa\u00e7\u00e3o de valores compostos, como arrays, e \u00e0 organiza\u00e7\u00e3o da pesquisa em dados de texto completo ou estruturas JSON.\n
Foi adicionada a capacidade de criar vis\u00f5es materializadas e chaves para particionamento de tabelas com \u00edndices que possuem a caracter\u00edstica \u2018unique\u2019, que n\u00e3o utilizam a estrutura B-tree.\n
Aumentada a performance geral de bloqueios para consultas que trabalham com um grande n\u00famero de tabelas, al\u00e9m de melhorias na manipula\u00e7\u00e3o de consultas em tabelas particionadas que aceleram o descarte de se\u00e7\u00f5es n\u00e3o utilizadas e opera\u00e7\u00f5es de jun\u00e7\u00e3o (JOIN).\n
Aceleradas opera\u00e7\u00f5es com texto, como fun\u00e7\u00f5es de convers\u00e3o para mai\u00fasculas\/min\u00fasculas. Adicionado o modo PG_UNICODE_FAST para acelerar a considera\u00e7\u00e3o das propriedades de localidade dos caracteres Unicode.\n
Foi implementada a possibilidade de manter estat\u00edsticas do planejador de consultas ap\u00f3s atualiza\u00e7\u00f5es entre lan\u00e7amentos significativos do PostgreSQL. Essa mudan\u00e7a evita a execu\u00e7\u00e3o da opera\u00e7\u00e3o intensiva em recursos \u2018ANALYZE\u2019 ap\u00f3s a inicializa\u00e7\u00e3o de uma nova vers\u00e3o, at\u00e9 que essa opera\u00e7\u00e3o seja conclu\u00edda, o que havia causado uma queda no desempenho do SGBD.\n
Aumentou o desempenho da ferramenta pg_upgrade, usada para automatizar a transi\u00e7\u00e3o para uma nova vers\u00e3o significativa do PostgreSQL. As otimiza\u00e7\u00f5es s\u00e3o especialmente not\u00e1veis ao atualizar bancos de dados que cont\u00eam um grande n\u00famero de objetos, como tabelas e sequ\u00eancias. Para acelerar a execu\u00e7\u00e3o do pg_upgrade, tamb\u00e9m foi adicionado o par\u00e2metro «—jobs N» para paralelizar verifica\u00e7\u00f5es em N threads e o par\u00e2metro «—swap» para trocar diret\u00f3rios de dados inteiros sem criar refer\u00eancias, sem clonagem e sem c\u00f3pia de arquivos.\n
Adicionada a suporte a colunas geradas virtualmente, cujo valor \u00e9 calculado em tempo real durante a execu\u00e7\u00e3o das consultas, sem ser salvo em disco. Se na express\u00e3o «CREATE TABLE…» para colunas geradas estiver apenas a palavra-chave «GENERATED» sem especificar o tipo (STORED ou VIRTUAL), ent\u00e3o a nova variante \u00e9 aplicada por padr\u00e3o em vez da antiga implementa\u00e7\u00e3o. Na implementa\u00e7\u00e3o antiga, os valores eram gerados durante opera\u00e7\u00f5es «INSERT» ou «UPDATE» e salvos em disco para uso posterior. A desvantagem das colunas geradas virtualmente \u00e9 a impossibilidade de us\u00e1-las em \u00edndices, enquanto a vantagem \u00e9 a possibilidade de realizar normaliza\u00e7\u00e3o e modifica\u00e7\u00e3o de dados em tempo real (relevante ao trabalhar com dados JSON). Quanto \u00e0s colunas geradas armazenadas cl\u00e1ssicas, a nova vers\u00e3o agora oferece suporte \u00e0 replica\u00e7\u00e3o l\u00f3gica.\n
Nos comandos INSERT, UPDATE, DELETE e MERGE, implementou-se a possibilidade de retornar valores antigos (OLD) e atuais (CURRENT) na express\u00e3o RETURNING. Por exemplo, «UPDATE… RETURNING WITH (OLD AS o, NEW AS n) o.*, n.*.»\n
Adicionada a fun\u00e7\u00e3o uuidv7() para gerar identificadores \u00fanicos aleat\u00f3rios no formato UUIDv7. Ao contr\u00e1rio da antiga fun\u00e7\u00e3o para gera\u00e7\u00e3o de UUID (gen_random_uuid), que agora tamb\u00e9m est\u00e1 dispon\u00edvel sob o nome uuidv4(), o UUIDv7 inclui a hora de gera\u00e7\u00e3o, al\u00e9m do valor aleat\u00f3rio. A presen\u00e7a de partes ordenadas no valor UUID (os primeiros 12 caracteres — tempo epochal, e os 18 seguintes — valor aleat\u00f3rio) melhora a efici\u00eancia de ordena\u00e7\u00e3o e indexa\u00e7\u00e3o, o que \u00e9 relevante, uma vez que UUIDs s\u00e3o geralmente usados para chaves prim\u00e1rias (por exemplo, chaves criadas em per\u00edodos pr\u00f3ximos s\u00e3o colocadas pr\u00f3ximas umas das outras no \u00edndice).\n
Na opera\u00e7\u00e3o «LIKE», foi implementado suporte a compara\u00e7\u00f5es textuais utilizando propriedades de locale indeterminadas «collation», permitindo que as compara\u00e7\u00f5es levem em considera\u00e7\u00e3o o significado dos caracteres (por exemplo, ao comparar, sinais de acentua\u00e7\u00e3o podem n\u00e3o ser considerados). Foi adicionada a fun\u00e7\u00e3o CASEFOLD para alterar o caso dos caracteres conforme as propriedades de locale «collation» (por exemplo, alguns caracteres t\u00eam mais de duas vers\u00f5es min\u00fasculas ou, ao comparar, exigem a convers\u00e3o para mai\u00fasculas, e n\u00e3o para min\u00fasculas).\n
Foi adicionada a possibilidade de usar restri\u00e7\u00f5es temporais (temporal constraint). Nos valores «PRIMARY KEY» e «UNIQUE», para adicionar restri\u00e7\u00f5es temporais deve-se usar a express\u00e3o «WITHOUT OVERLAPS», e no valor «FOREIGN KEY» \u2014 a express\u00e3o PERIOD. Por exemplo, ao definir chaves prim\u00e1rias, \u00e9 poss\u00edvel limitar chaves com intervalos de tempo sobrepostos.\n
Foi adicionada o comando «CREATE FOREIGN TABLE … LIKE command» para criar um esquema de tabela externa com base na defini\u00e7\u00e3o de uma tabela local.\n
Adicionada a suporte para conex\u00e3o a SGBD usando autentica\u00e7\u00e3o baseada em OAUTH 2.0 com um token de acesso em vez de senha. O uso de OAUTH permite n\u00e3o armazenar senhas no BD, identificar usu\u00e1rios atrav\u00e9s de servi\u00e7os externos e usar recursos como autentica\u00e7\u00e3o de dois fatores e ponto de entrada \u00fanico (SSO).\n
Adicionada a fun\u00e7\u00e3o ssl_tls13_ciphers(), pela qual \u00e9 poss\u00edvel determinar a lista de algoritmos de criptografia permitidos ao conectar usando o protocolo TLSv1.3.\n
Apoio \u00e0 autentica\u00e7\u00e3o usando o algoritmo md5 para hashing de senhas foi transferido para a categoria de obsoleto e programado para remo\u00e7\u00e3o. Em vez de md5, recomenda-se o uso do algoritmo SCRAM (SCRAM-SHA-256), que surgiu no PostgreSQL 10. Tamb\u00e9m \u00e9 observada a implementa\u00e7\u00e3o do suporte para a passagem de autentica\u00e7\u00e3o baseada em SCRAM ao conectar via postgres_fdw e dblink a servidores PostgreSQL externos.\n
Ao executar a opera\u00e7\u00e3o «EXPLAIN ANALYZE», s\u00e3o apresentadas informa\u00e7\u00f5es sobre o n\u00famero de opera\u00e7\u00f5es de busca em \u00edndices durante a varredura do \u00edndice e o n\u00famero de acessos a buffers durante a execu\u00e7\u00e3o da consulta. A sa\u00edda «EXPLAIN ANALYZE VERBOSE» agora inclui estat\u00edsticas sobre CPU, WAL e intensidade das opera\u00e7\u00f5es de leitura. A tabela pg_stat_all_tables foi atualizada com informa\u00e7\u00f5es sobre o tempo gasto nas opera\u00e7\u00f5es de VACUUM e an\u00e1lise de tabelas. Estat\u00edsticas sobre a intensidade de entrada\/sa\u00edda e carga no WAL em rela\u00e7\u00e3o a conex\u00f5es espec\u00edficas foram adicionadas. Informa\u00e7\u00f5es de diagn\u00f3stico sobre conflitos durante opera\u00e7\u00f5es de grava\u00e7\u00e3o durante a replica\u00e7\u00e3o l\u00f3gica foram inclu\u00eddas em pg_stat_subscription_stats e nos logs.\n
Nas novas instala\u00e7\u00f5es, a utiliza\u00e7\u00e3o de somas de verifica\u00e7\u00e3o para verificar a integridade dos dados armazenados \u00e9 ativada por padr\u00e3o. Para reverter esse comportamento ao executar initdb, deve-se especificar a op\u00e7\u00e3o «--no-data-checksums».\n
Foi adicionado ao utilit\u00e1rio pg_createsubscriber a flag «--all» para criar replica\u00e7\u00f5es l\u00f3gicas com um \u00fanico comando para todos os bancos de dados.\n
Uma nova vers\u00e3o (3.2) do protocolo utilizado para intera\u00e7\u00e3o com utilit\u00e1rios externos e implementado na biblioteca libpq foi realizada. A \u00faltima atualiza\u00e7\u00e3o do protocolo ocorreu no PostgreSQL 7.4 (ano de 2003). Na biblioteca libpq, a vers\u00e3o 3.0 continua sendo utilizada por padr\u00e3o. <\/ul>\n