From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Linder Poclaba Lazaro <linderlpl(at)gmail(dot)com> |
Cc: | Fede Martinez <federicoemartinez(at)gmail(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-03 21:11:47 |
Message-ID: | 20140203211147.GK10723@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
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
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
From | Date | Subject | |
---|---|---|---|
Next Message | Linder Poclaba Lazaro | 2014-02-03 22:59:53 | Re: LIMIT y OFFSET hacen lenta un QUERY |
Previous Message | Linder Poclaba Lazaro | 2014-02-03 19:14:55 | Re: LIMIT y OFFSET hacen lenta un QUERY |