Re: LIMIT y OFFSET hacen lenta un QUERY

Al final como quedo la query que funciona bien?

El 3 de febrero de 2014, 19:59, Linder Poclaba Lazaro
<linderlpl(at)gmail(dot)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.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 <alvherre(at)2ndquadrant(dot)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
>>
>
>