Al final como quedo la query que funciona bien?
El 3 de febrero de 2014, 19:59, Linder Poclaba Lazaro <[email protected]>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.id y > 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 > <[email protected]>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 >> > >
