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 <alvhe...@alvh.no-ip.org> - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
