Novidades no planejador de consultas do Postgres 16

Novidades no planejador de consultas do PostgreSQL 16

• O PostgreSQL 16 introduz muitas melhorias no planejador de consultas, permitindo que muitas consultas SQL sejam executadas mais rapidamente do que nas versões anteriores.
• É possível ver essas melhorias do planejador nas notas de lançamento do PG16, mas como há muitas mudanças em cada versão do PostgreSQL, é difícil fornecer explicações detalhadas para cada uma delas.
• Neste post de blog, é apresentada uma análise aprofundada de 10 melhorias feitas no planejador de consultas do PostgreSQL 16, junto com comparações da saída do planejador entre o PG15 e o PG16 e exemplos do que mudou.

10 melhorias no planejador de consultas do PostgreSQL 16

• Ordenação incremental: introduzida pela primeira vez no PostgreSQL 13, a ordenação incremental aproveita quando parte do conjunto de resultados já está ordenada por uma ou mais colunas iniciais, realizando a ordenação apenas das colunas restantes.
• Agregação usando dados ordenados: o planejador de consultas do PostgreSQL 16 agora tenta formar planos que forneçam linhas ao nó de agregação já em ordem classificada.
• Memoização: introduzido pela primeira vez no PostgreSQL 14, o nó de plano de memoização atua como uma camada de cache para evitar buscas repetidas de valores duplicados.
• Anti-join: o PostgreSQL 16 permite fazer hash da tabela menor ao executar um anti-join.
• Parallel hash join: o PostgreSQL 16 oferece suporte a parallel hash join para os tipos de junção FULL e RIGHT.
• Otimização de funções de janela: o PostgreSQL 16 permite usar funções de janela mais rápidas ao usar o modo ROWS em vez do modo RANGE.
• Otimização de funções de janela sempre crescentes: o PostgreSQL 16 expande as otimizações para funções de janela como ntile(), cume_dist() e percent_rank().
• Remoção de join em tabelas particionadas: o PostgreSQL 16 permite a otimização de remoção de LEFT JOIN em tabelas particionadas.
• Uso de Limit para consultas DISTINCT: o planejador de consultas do PostgreSQL 16 não inclui nós de plano para eliminar duplicações no resultado quando consegue detectar que todas as linhas contêm o mesmo valor.
• Flexibilização das regras para Merge Join: ao considerar Merge Join, o planejador de consultas do PostgreSQL 16 verifica se pelo menos uma coluna inicial está corretamente ordenada, em vez de exigir que a ordem das linhas corresponda exatamente.

Opinião do GN⁺

• As melhorias no planejador de consultas do PostgreSQL 16 desempenham um papel importante no aumento do desempenho do banco de dados. Em especial, recursos como ordenação incremental e memoização permitem executar consultas complexas com mais eficiência.
• Essas melhorias serão muito úteis para desenvolvedores e administradores de banco de dados que usam PostgreSQL, especialmente em sistemas que lidam com grandes volumes de dados, onde os ganhos de desempenho poderão ser percebidos com clareza.
• O esforço contínuo de inovação e aprimoramento da comunidade PostgreSQL impulsiona o avanço da tecnologia de bancos de dados open source, oferecendo melhores soluções de gerenciamento de dados para usuários e empresas.

[GN⁺]

Opiniões no Hacker News

• Há quem ache que seria bom se o planejador de consultas do Postgres pudesse replanejar uma consulta no meio da execução. A falta de informações sobre a distribuição dos dados pode levar à criação de planos de consulta ineficientes, o que pode afetar bastante o tempo de execução. Se uma consulta estiver andando mais lentamente do que o esperado, seria necessário um recurso para replanejá-la com base nas informações de progresso atuais. No entanto, como o Postgres oferece suporte a consultas em streaming, mudar o plano no meio da execução exigiria mudanças consideráveis na infraestrutura.
• Um usuário diz usar explain.dalibo.com e www.pgexplain.dev como ferramentas de visualização de consultas. Ambas fornecem resultados de saída semelhantes.
• Há a opinião de que melhorar o planejador de consultas é uma parte importante de um banco de dados, mas isso geralmente só fica evidente quando ele não funciona como se deseja. Foi compartilhada a experiência de que o compilador JIT (Just-In-Time) das versões mais recentes do Postgres parece ter heurísticas pouco robustas no momento do uso, podendo deixar cargas pequenas mais lentas, e por isso pode ser melhor desativar o JIT.
• Há curiosidade sobre com que frequência as mudanças realmente fazem efeito em consultas reais, especialmente a alteração de “usar Limit em vez de DISTINCT quando possível”, e se isso de fato se aplica em casos práticos. Também há uma pergunta sobre se os desenvolvedores do Postgres têm informações a esse respeito.
• Há a opinião de que seria bom existir um “modo estrito” para testes de aplicação. Nesse modo, seria retornado um erro quando não houvesse índice para melhorar a consulta, e os índices necessários poderiam ser criados com o comando CREATE INDICES FOR <sql>. Também foi proposto um modo de criação automática de índices para desenvolvimento e uso interativo.
• Um amigo de um usuário trabalha como DBA da Microsoft para pequenas e médias empresas e afirma que não é possível fazer trabalhos sérios com Postgres. Ele teria se surpreendido ao saber que o Postgres não teria um planejador de consultas, mas isso é informação incorreta. Há uma pergunta sobre a credibilidade da afirmação de que o MSSQL consegue lidar com trabalhos em escala maior do que o Postgres.
• Foi levantada a dúvida sobre por que o Postgres não implementa hints.
• Há uma pergunta sobre por que o recurso anunciado pela Citus Data apareceu em outro lugar em vez de no postgresql.org, e se se trata de um recurso pago ou de uma extensão open source.
• Há uma pergunta sobre em que momento o Postgres pode usar um índice para acelerar consultas com IS NOT DISTINCT FROM.
• Um comentário foi denunciado e marcado com flag.