Aplique los consejos que me dieron Raul y Alvaro y mejoro la consulta a 3 segundos, tengo que estudiar la documentacion de EXPLAIN para ver porque cambia el plan para order by asc y desc.
Gracias a todos nuevamente. El 4 de febrero de 2014, 13:46, Fede Martinez <federicoemarti...@gmail.com>escribió: > Al final como quedo la query que funciona bien? > > > El 3 de febrero de 2014, 19:59, Linder Poclaba Lazaro <linder...@gmail.com > > escribió: > > gracias a todos por su recomendaciones las cuales fueron implementadas y >> mejoro considerablemente el tiempo de respuesta de la consulta. >> >> analizando los resultado del comando EXPLAIN ANALYZE, me surgieron muchas >> dudas, el plan cambia cuando coloco despues del WHERE, el order by b.idy >> order by >> b.id desc porque? >> >> dejo lo links del explain >> >> order by b.id >> >> http://explain.depesz.com/s/hs51 >> >> order by b.id desc >> >> http://explain.depesz.com/s/PO7 >> >> Gracias por su tiempo nuevamente. >> >> >> >> >> El 3 de febrero de 2014, 17:11, Alvaro Herrera >> <alvhe...@2ndquadrant.com>escribió: >> >> Linder Poclaba Lazaro escribió: >>> >>> > LEFT JOIN dj_documento.cadena_documentos cd on >>> cd.idbien = b.id >>> > where identidad=78 and i.idbien not in (select >>> idbien FROM dj_activos.bajasbienes) >>> >>> Hmm, el NOT IN es complicado de optimizar por la posible presencia de >>> NULLs en los valores de la subconsulta. No miré en detalle el plan >>> (sólo vi que ahí hay un "filter NOT hashed subplan") pero ¿qué pasa si >>> reemplazas el NOT IN por un NOT EXISTS? (Me parece que deberías >>> asegurarte de tener índices en dj_activos.bajasbienes como en >>> inmueble.idbienjpara que pueda cambiar de un seqscan/not in subplan a un >>> nested loop u otro plan mejor; aún cuando no mejore esta consulta >>> significativamente me parece que eso será necesario a medida que crezcan >>> las tablas) >>> >>> -- >>> Álvaro Herrera http://www.2ndQuadrant.com/ >>> PostgreSQL Development, 24x7 Support, Training & Services >>> >> >> >
