Otimização de Consultas Postgres: Lorikeet Acelera Desempenho em até 1.000x com Simples Typecast

A otimização de 1.000 vezes da Lorikeet no PostgreSQL girou em torno de uma sutileza entre os tipos de dados timestamp e timestamptz e sua interação com o Row Level Security (RLS). A função NOW() no Postgres retorna um timestamptz. Quando comparado a uma coluna createdAt do tipo timestamp, o banco precisava realizar uma comparação entre tipos de dados diferentes. Embora o Postgres tivesse um índice no (owner, createdAt), a parte createdAt não era usada eficientemente.

O problema é que o PostgreSQL classifica funções como "leakproof" (à prova de vazamento) ou "not leakproof" para garantir a segurança dos dados sob RLS. Historicamente, a conversão de timestamp para timestamptz podia causar um erro de underflow, vazando informações sobre os dados ocultos. Mesmo após a correção desse bug em 2020, a classificação de "not leakproof" da função de comparação permaneceu. Isso impediu o uso do índice, forçando um filtro lento. O simples typecast NOW()::timestamp alinhou os tipos de dados, tornando a comparação "leakproof" e permitindo que o índice fosse totalmente utilizado.

Este caso da Lorikeet expõe uma evolução interessante na compreensão dos mecanismos internos do PostgreSQL. Um bug histórico de conversão entre timestamp e timestamptz, que poderia vazar informações sob RLS, foi corrigido em 2020. No entanto, a classificação da função de comparação como "not leakproof" não foi atualizada. Além disso, a fonte da notícia menciona que, "apenas no mês passado" (julho de 2026), outro bug foi encontrado, onde essa comparação ainda poderia gerar resultados incorretos durante ajustes de horário de verão. Essa linha do tempo mostra que mesmo em sistemas maduros, detalhes técnicos podem ter efeitos cascata e exigem vigilância contínua.

A história da Lorikeet é um lembrete de que a performance em sistemas de dados não é só sobre hardware ou grandes algoritmos. Pequenos detalhes, como a gestão precisa de tipos de dados e o entendimento das particularidades de recursos como RLS, são cruciais. Uma diferença sutil de tipo pode transformar uma consulta rápida em um gargalo massivo. Para quem trabalha com engenharia de dados, analytics e arquitetura, essa é uma lição clara: otimizações significativas muitas vezes estão escondidas em interações inesperadas entre componentes do banco de dados, exigindo um mergulho profundo no comportamento do sistema.