Re: prueba de jit en postgres 11

Hola Alvaro

Muchas Gracias por la respuesta, el rendimiento de la máquina no fue el
esperado, la carga de cpu subió muchísimo y algunas consultas triviales
se demoran demasiado, me tocó poner los reportes y bases en la otra
réplica (la no JIT). Estoy registrando en el log las sentencias y con estas
pretendo afinar la réplica JIT, por lo tanto en este momento la tengo
solo como backup

El mié., 10 de jun. de 2020 a la(s) 11:53, Alvaro Herrera (
alvherre(at)2ndquadrant(dot)com) escribió:

> 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
>

--
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate