Re: prueba de jit en postgres 11

Hellmuth Vargas escribió:

Hola

> Entiendo que JIT básicamente aplica para la optimización de consultas
> (diciéndolo de forma coloquiar)

Sí, la idea es que algunos pasos en la ejecución de consultas se pueden
"compilar" a código específico para esa operación específica, lo que
resulta más eficiente que ejecutar el código genérico. Pero se incurre
en un costo de hacer esa compilación. Si se va a ejecutar pocas veces,
no vale la pena hacer la compilación, porque el menor tiempo de
ejecución lo vas a perder en la compilación.

> Tengo varias preguntas:
>
> - Los datos o en general la replica puede llegar a corromperse (porque la
> master no tiene jit) o si eventualmente llega a ser master (promoviéndola),
> las replicas existentes podrían apuntar a esta?

Por diseño, las réplicas nunca escriben datos, así que aún si hubiera
un tremendo bug en el JIT no es posible que resulte en corrupción de
datos si lo ejecutas en una réplica. Por otra parte, el JIT actualmente
sólo se aplica en operaciones de lectura, no en escrituras, así que aún
si lo pusieras en el primario, no es posible que resulte en corrupción.

La única opción para que tengas un problema de ese tipo es que JIT tenga
algún bug que cause que el sistema se caiga. Esto no es imposible pero
yo no he visto reportes de que esto haya sucedido.

> - los valores por defecto de los parámetros jit_above_cost,
> jit_inline_above_cost y jit_optimize_above_cost son altos, en general no
> se encuentra mucha información para la configuración de estos, que valores
> deberían establecerse (por criterios como RAM, o CPU o tipo de disco duro,
> etc como se hacer con otros parámetros).. o debo tomar algunas de las
> consultas pesadas y empezar a jugar con estos?

Sí, experimentar es lo mejor. Piensa que el tiempo de compilación es de
unos cuantos cientos de milisegundos, así que una consulta rápida no se
verá beneficiada.

Las operaciones que actualmente se optimizan son:

1. "deforming" de tuplas (es decir, convertir la representación "muchos
bytes en disco" de una tupla separándola en los valores de cada columna)

2. ejecución de expresiones (es decir, tomar cosas como "columna + 10"
y convertirla en código nativo de CPU que ejecuta la suma de dos
valores donde uno es constante y el otro se lee de la tupla)

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services