Re: LIMIT y OFFSET hacen lenta un QUERY

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
>