Como o pgrust deixou queries analíticas em Postgres até 300x mais rápidas

O projeto pgrust lançou a versão 0.2, focada em performance, e publicou um detalhamento técnico de como reconstruiu o motor de queries do Postgres. Segundo o autor, a nova versão é 10x mais rápida que a anterior. Nos números divulgados, o pgrust é 30% mais rápido que o Postgres em benchmarks OLTP e 300x mais rápido no ClickBench, o benchmark analítico do ClickHouse, ficando inclusive à frente do próprio ClickHouse.

Só o motor de queries respondeu por cerca de 10x desse fator de 300x.

Por que sobra espaço para otimizar

O argumento do texto é histórico: o Postgres nasceu nos anos 80, quando o gargalo dominante era I/O de disco. O autor aponta três mudanças que alteraram esse cenário:

• Muitos datasets hoje cabem em RAM, eliminando boa parte do I/O de disco.
• Cargas analíticas varrem dados em massa, e o gargalo passou a ser CPU ou banda de memória.
• Discos NVMe são centenas de vezes mais rápidos que HDs.

Resultado: velocidade de CPU e memória pesam mais do que pesavam. E o motor de queries é justamente o maior consumidor de CPU num banco.

O exemplo que expõe o overhead

Para isolar o efeito, o autor usa uma query simples que soma os primeiros 500 milhões de números:

CREATE TABLE my_table AS select col::float8 from generate_series(1.0, 500000000.0) g(col);
SELECT SUM(col) FROM my_table;

No Postgres 18.4, com queries paralelas desativadas, isso leva cerca de 20 segundos. O mesmo cálculo em um laço for em Rust roda em 358ms, cerca de 55x mais rápido. Segundo o texto, dois dos maiores focos de overhead do Postgres são o locking e o parsing do formato de armazenamento para extrair as tuplas relevantes.

Volcano model, o ponto de partida

O Postgres usa o executor no estilo Volcano model, em que cada nó do plano implementa um método next() que retorna uma linha por vez. É simples de implementar (o Postgres tem mais de 40 tipos de nós de plano), mas custa caro. Uma versão mínima desse modelo em Rust, sem os demais componentes do Postgres, já roda em 1,3s, bem abaixo dos 20s, mas ainda longe do laço puro.

A partir daí, o autor aplica três otimizações:

1. Batching. Em vez de processar uma linha por chamada, o motor passa a operar em lotes (BATCH = 1024), com o buffer alocado na pilha para evitar alocações de memória durante a execução. Tempo: cai para ~480ms.

2. Operator fusion. Quando duas operações costumam andar juntas (aqui, o scan sequencial e a soma), dá para fundi-las em um único nó, eliminando a cópia do buffer que virava o novo hotspot. Tempo: ~358ms, empatando com o laço for. O autor admite que isso é "trapaça" ao hardcodar casos comuns, e aponta a compilação JIT como caminho geral (assunto de um próximo post).

3. SIMD. Instruções que aplicam uma operação a vários dados de uma vez. Usando intrinsics de aarch64, o tempo cai para 135ms, quase 3x mais rápido que o laço for e 10x mais que o Volcano original. O autor escolheu somar floats justamente porque o compilador tende a não vetorizar automaticamente nesse caso: aritmética de ponto flutuante não é associativa, então mudar a ordem da soma pode alterar levemente o resultado.

O resumo dos tempos:

| implementação | tempo | speedup | |---|---|---| | Postgres | ~20s | - | | Volcano model | 1,3s | 1x | | + batching | 480ms | 2,7x | | + operator fusion | 358ms | 3,6x | | + SIMD | 135ms | 9,6x |

O que isso muda para quem trabalha com dados no Brasil

Vale a leitura crítica: os números vêm do próprio projeto, medidos em uma instância AWS c8g.4xlarge (Graviton4, 16 vCPU), com PostgreSQL 18.4, dados quentes em shared buffers e mediana de 5 execuções, sem paralelismo. O exemplo isola o motor de queries e não é uma comparação apples-to-apples com uma carga real de produção.

Ainda assim, os conceitos são úteis para quem toca BI e engenharia de dados por aqui. Antes de trocar de banco, times brasileiros que rodam analytics em Postgres podem verificar se estão aproveitando paralelismo de queries e se o workload não seria melhor servido por soluções colunares. Para quem quiser acompanhar ou testar, o pgrust mantém repositório no GitHub e site oficial em pgrust.com, com um post futuro prometido sobre compilação JIT.

Fonte: Hacker News