- Após a introdução de uma nova metodologia de construção de compilador JIT (
copy-patch) no Python 3.13, decidiu-se tentar aplicá-la ao PostgreSQL.
- É apresentada uma nova abordagem chamada
pg-copyjit, um método para melhorar a velocidade do servidor PostgreSQL.
- Todo o código é experimental, e uma revisão por especialistas é necessária antes do uso em ambientes reais de produção.
No começo não havia JIT, e depois surgiu o compilador JIT com LLVM
- A compilação JIT com LLVM foi introduzida no PostgreSQL, mas o LLVM tem aspectos que não o tornam ideal para JIT.
- As otimizações do LLVM têm custo elevado e, sem elas, a própria compilação pode perder o sentido.
- Como a estimativa de custo de consultas do PostgreSQL não tem relação direta com o tempo real de execução, muitos usuários desativam o compilador JIT.
Em 2021, o copy-and-patch foi descrito
- Há necessidade de gerar código rápido e suficientemente bom o mais rápido possível.
- A abordagem
copy-patch gera código rapidamente usando stencils (funções-modelo) escritos em C.
- Os stencils são copiados para uma nova área de memória, os espaços são preenchidos, e então é possível saltar diretamente para a função “compilada”.
Introduzindo copy-and-patch no PostgreSQL
- Construir um novo motor JIT para o PostgreSQL não é tão difícil, e propõe-se transformar o LLVM em um plugin para permitir a introdução de outros compiladores JIT.
- Basta fornecer uma única função
_PG_jit_provider_init e inicializar três callbacks: compile_expr, release_context e reset_after_error.
- O algoritmo
copy-patch é simples: localizar e adicionar o stencil de cada opcode, preenchendo os espaços com os valores necessários.
Estado atual
- Funciona no PostgreSQL 16 e, por enquanto, suporta apenas AMD64.
- A geração de código é concluída em algumas centenas de microssegundos, o que permite seu uso até em consultas curtas.
- Ainda não está na fase de otimização, mas já é possível ver melhora de desempenho em relação ao interpretador.
- Há poucos opcodes implementados, mas, para consultas ainda não suportadas, o interpretador do PostgreSQL assume a execução.
O que falta fazer...
- Isto está no estágio de prova de conceito, e ainda não se considera como torná-lo fácil de compilar ou empacotar.
- O foco está em implementar mais opcodes e encontrar otimizações.
- A adaptação para outras arquiteturas também está sendo seriamente considerada.
Agradecimentos
- Agradece ao atual empregador, Entr’ouvert, por apoiar os colegas para que pudessem dedicar tempo a este projeto.
- Agradece também aos amigos DBAs e recomenda experimentar o PoWA.
Opinião do GN⁺
- Este artigo apresenta uma nova abordagem para melhorar o desempenho do servidor de banco de dados PostgreSQL. Isso pode ser interessante para administradores de banco de dados e desenvolvedores.
- Antes de aplicar código experimental em ambientes reais de produção, são necessários testes e validações rigorosos. Isso ajuda a evitar riscos como perda de dados ou indisponibilidade.
- Em comparação com compiladores JIT existentes, como o LLVM, a abordagem
copy-patch pode permitir geração de código mais rápida, sendo útil até para consultas curtas.
- Se essa tecnologia for amplamente aceita pela comunidade PostgreSQL, poderá abrir um novo caminho para a otimização de desempenho de bancos de dados, junto com a expansão do suporte a várias arquiteturas.
- Sob uma perspectiva crítica, ainda está em estágio inicial, e são necessárias mais pesquisa e desenvolvimento para entender como o ganho de desempenho aparecerá em ambientes reais de produção.
Ainda não há comentários.