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 ( alvhe...@2ndquadrant.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
