- Después de que Python 3.13 introdujera una nueva metodología para construir compiladores JIT (
copy-patch), se decidió probar su aplicación en PostgreSQL.
- Se presenta un nuevo enfoque llamado
pg-copyjit, que busca mejorar la velocidad del servidor PostgreSQL.
- Todo el código es experimental y requiere revisión de expertos antes de usarse en un entorno de producción real.
Al principio no había JIT, y luego apareció el compilador LLVM JIT
- Se introdujo compilación JIT con LLVM en PostgreSQL, pero LLVM tiene aspectos que no encajan bien con la compilación JIT.
- Las optimizaciones de LLVM son costosas, y si no se usan, la compilación en sí puede perder sentido.
- La estimación de costo de consultas en PostgreSQL no se relaciona directamente con el tiempo real de ejecución, por lo que muchos usuarios desactivan el compilador JIT.
En 2021, se describió copy-and-patch
- Existe la necesidad de generar código rápido y suficientemente bueno lo más rápido posible.
- El enfoque
copy-patch genera código rápidamente usando stencils (funciones plantilla) escritos en C.
- Se copia el stencil a una nueva región de memoria y se rellenan los huecos para poder saltar de inmediato a la función “compilada”.
Introducir copy-and-patch en PostgreSQL
- Construir un nuevo motor JIT para PostgreSQL no es tan difícil, y se propone convertir LLVM en un plugin para permitir la incorporación de otros compiladores JIT.
- Basta con proporcionar una única función
_PG_jit_provider_init e inicializar tres callbacks: compile_expr, release_context y reset_after_error.
- El algoritmo
copy-patch es simple: se busca y agrega un stencil para cada opcode, y luego se rellenan los huecos con los valores necesarios.
Estado actual
- Funciona en PostgreSQL 16 y por ahora solo soporta AMD64.
- La generación de código se completa en unos pocos cientos de microsegundos, por lo que puede usarse incluso en consultas cortas.
- Aún no está en fase de optimización, pero ya se puede ver una mejora de rendimiento frente al intérprete.
- Hay pocos opcodes implementados, pero para las consultas que todavía no son compatibles, el intérprete de PostgreSQL se encarga de ejecutarlas.
Pendiente por hacer...
- Esto está en etapa de prueba de concepto, y todavía no se está considerando facilitar su compilación o empaquetado.
- El foco está en implementar más opcodes y encontrar optimizaciones.
- También se está considerando seriamente su portabilidad a otras arquitecturas.
Agradecimientos
- Se agradece a su empleador actual, Entr’ouvert, por apoyar que sus colegas puedan dedicar tiempo a este proyecto.
- También agradece a sus amigos DBA y recomienda probar PoWA.
Opinión de GN⁺
- Este artículo presenta un nuevo enfoque para mejorar el rendimiento del servidor de base de datos PostgreSQL. Puede resultar interesante para administradores de bases de datos y desarrolladores.
- Antes de aplicar código experimental en un entorno de producción real, se necesitan pruebas y validaciones exhaustivas. Esto busca evitar riesgos como pérdida de datos o tiempo de inactividad.
- En comparación con compiladores JIT existentes como LLVM, el enfoque
copy-patch puede permitir una generación de código más rápida, lo que también podría hacerlo útil para consultas cortas.
- Si esta tecnología logra una adopción amplia dentro de la comunidad de PostgreSQL, podría abrir una nueva etapa en la optimización del rendimiento de bases de datos junto con un soporte más amplio para distintas arquitecturas.
- Desde una mirada crítica, todavía está en una etapa temprana y se necesita más investigación y desarrollo para ver cómo se traducirá la mejora de rendimiento en entornos de producción reales.
Aún no hay comentarios.