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