Ruben Fitó escribió: > - Finalmente, hemos conseguido que el analize de los PREPARE nos > compute un coste aproximado a cero. En teoría, en este punto hemos > conseguido optimizar al máximo las consultas de la función, pero > realmente > no és asi..... Más adelante os explico
¿cómo haces el EXPLAIN ANALYZE? Para una consulta que das con PREPARE y EXECUTE, lo que deberías hacer es: PREPARE consulta AS select ... EXPLAIN ANALYZE EXECUTE consulta(1, 2, 3) Es muy diferente que dar simplemente un EXPLAIN ANALYZE select... El optimizador va a tratar estas cosas como diferentes. > - Al ver tal desbarajuste, hemos echo un ANALIZE directamente de cada > una de las QUERY de la función, dándole datos concretos, con la sorpresa > que el plan a utilizar es diferente segun el valor aportado. Correcto. > - Finalmente, hemos hecho la suposición de que la tabla es demasiado > grande, y como POSTGRES nunca se equivoca, hemos optado por acotar ciertas > consultas respecto un rango de fechas, con lo que hemos mejorado algunos > tiempos de respuesta para los valores más problemáticos, pero para los que > el coste era mínimo, ahora el tiempo de respuesta ha aumentado. No, la tabla no es demasiado grande, y sí, Postgres sí se equivoca. Es posible que tengas que cambiar algunos parámetros, como effective_cache_size, y random_page_cost. > - Qué tipo de consultas són más lentas que otras?? Las que leen más disco son más lentas que las que leen menos disco. Y las que leen disco aleatoriamente son peores que las que leen secuencialmente. > - Es más óptimo hacer querys des de SRC en vez de encapsular-las en > funciones de BBDD'??. Normalmente sí. Encapsular cosas en funciones puede crear "barreras de optimización". > - La funciones tienen un plan predefinido en el momento de crear-las, o > segun se llaman va cambiando?? Y Si está predefinido por defecto, existe la > manera para que recalcule el plan cada vez que se ejecute?? No, el plan se crea en la primera ejecución, queda en cache y después se puede reusar. Creo que en 9.2 cambió la cosa, y puede haber un "custom plan" que significa que cuando el plan en cache no es muy bueno, se crea un plan específico para los parámetros específicos que esa ejecución usará. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services - Enviado a la lista de correo pgsql-es-ayuda ([email protected]) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
