El 21/10/11 09:42, Mario Sileone escribió:
Gracias por tu aporte, pero esta todo en orden por ese lado.
Leyendo un poco mas, el planificador de Postgres utiliza el effective_cache_size para optimizar si vale la pena hacer index scan, seq scan,etc. Actualmente estaba en 128. Es posible, que el problema está en que esta consulta trabaja cerca del límite de memoria que necesita la ejecución y se produce el cambio cuando lee X cantidad más de registros, y allí está la diferencia?

Saludos y gracias

Mario Sileone
Tambien se me ocurre que necesite ordenar y este pasando a ordenar en disco y no en memoria....habria que ver los dos explain analyze para ver que es lo que esta sucediendo realmente. Solo ideas....pero sin los explain y datos del servidor es dificil imaginar algo mas....

Saludos

Rodrigo

-
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

Responder a