From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Emanuel Calvo Franco <postgres(dot)arg(at)gmail(dot)com> |
Cc: | Lista Postgres <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Simulacion rowcount en 8.4 difiere de 8.3.5 |
Date: | 2009-08-12 00:31:31 |
Message-ID: | 20090812003131.GN16362@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Emanuel Calvo Franco escribió:
> El limit lo puse porque la tabla es enorme, no porque sea
> asi la consulta. Igualmente esta consulta en particular
> no es primordial. (es una prueba)
>
> Sin embargo, a simple vista no es una consulta compleja,
> no veo donde esta el cambio aún.
>
> Los planes en ambos motores no cambian. E inclusive
> manejan casi los mismos costos.
>
> Puse a correr la consulta con order by sobre 8.4 pero
> todavia esta corriendo... :S
El problema es synchronized_seqscans. Creo que ya habías tenido
problemas con eso una vez.
El problema que realmente tienes es que ese count() que tienes en el
subselect es rápido sólo para las primeras filas de la tabla. Mientras
más te acercas al final, más tiene que recorrer para obtener el count().
Cada uno de esos es un scan desde el principio de la tabla hasta ese
punto en particular.
--
Alvaro Herrera http://planet.postgresql.org/
"Cuando mañana llegue pelearemos segun lo que mañana exija" (Mowgli)
From | Date | Subject | |
---|---|---|---|
Next Message | Jorge Romeo | 2009-08-12 13:57:59 | RE: conectarse a un servidor postgres(linux) con pgadmin(windows) |
Previous Message | Emanuel Calvo Franco | 2009-08-11 22:53:16 | Re: Simulacion rowcount en 8.4 difiere de 8.3.5 |