From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Diego Ayala <netdiego81(at)gmail(dot)com> |
Cc: | Silvio Quadri <silvioq(at)gmail(dot)com>, Postgres Ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: problema con query lento |
Date: | 2011-04-14 16:47:57 |
Message-ID: | 1302799586-sup-758@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Excerpts from Diego Ayala's message of jue abr 14 13:37:26 -0300 2011:
> no, no es un problema, lo unico que tengo es la incognita que era que
> cambiando el campo del order by "item.nro_linea", me generaba este tiempo
> 0.33 ms, sin embargo, con el otro campo, item.id, me generaba un tiempo de
> casi 20 seg. Y lo que no me queda claro es que la misma consulta, en un
> servidor de desarrollo, con order by item.id me lo generaba en 0.75ms, y en
> la consulta con order by item.id en produccion 20 seg. de tiempo
> aproximado. El campo item.id es pk de la tabla item_solicitado, y nro_linea
> un campo integer.
Los planes cambian según los datos. Un plan que con pocos datos use un
nested loop puede cambiar a hash join o merge join cuando las tablas
crezcan. Si cambias el criterio de ordenamiento también puedes tener un
plan completamente diferente; sobre todo considerando que tus consultas
tienen cláusulas LIMIT.
--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
From | Date | Subject | |
---|---|---|---|
Next Message | Juan Manuel Acuña Barrera | 2011-04-14 16:58:24 | Re: [pgsql-es-ayuda] Presentación y solicitud de recomendación |
Previous Message | Diego Ayala | 2011-04-14 16:37:26 | Re: problema con query lento |