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
