Re: LIMIT y OFFSET hacen lenta un QUERY

From: Linder Poclaba Lazaro <linderlpl(at)gmail(dot)com>
To: Fede Martinez <federicoemartinez(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, raul andrez gutierrez alejo <raulandrez(at)gmail(dot)com>, pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: LIMIT y OFFSET hacen lenta un QUERY
Date: 2014-02-05 11:40:19
Message-ID: CANv3jyZnArf_TvHVq=v4sArk88O4uNZAY565PhdwCUpkNfGnUA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

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
<federicoemartinez(at)gmail(dot)com>escribió:

> 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.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 <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
>>>
>>
>>
>

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Gaston Rider 2014-02-05 13:46:28 Milisegundos entre dos campos
Previous Message Martín Marqués 2014-02-05 10:16:32 Re: dump y restore de base de datos grande