From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Miguel <mmiranda(at)123(dot)com(dot)sv> |
Cc: | "Javier Aquino H(dot)" <JAquino(at)LexusEditores(dot)com>, Jaime Casanova <systemguards(at)gmail(dot)com>, pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Re: consulta se demora mucho mas que antes |
Date: | 2006-03-31 19:27:33 |
Message-ID: | 20060331192733.GN14204@surnet.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Miguel escribió:
> Alvaro Herrera wrote:
>
> >La pregunta interesante es si haces una busqueda de un rango (A, A+1) y
> >luego del rango (A+1, A+2), al hacer una nueva busqueda de (A, A+1) se
> >demora 0,3 o 2,5?
>
> 0.3
Eso quiere decir que los working sets para al menos dos consultas caben
en el cache. (Observa que hay un porcentaje pequeño del working set que
es comun a ambas consultas, y que corresponde a las paginas de los
niveles más superiores del índice). Dependiendo de qué tan críticos
sean esos 2,2 (segundos?) de diferencia será lo importante que es tener
memoria (RAM física) adicional.
> Ok, moraleja de la historia, `` poner especial atencion al tipo de datos
> que usas en los indices ''
> en teoria esto esta resuelto a partir de la version 8?
Asi es, para ciertos tipos de datos. El tip que venia al pie de tu
mensaje lo confirma:
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Miguel | 2006-03-31 19:45:05 | Re: consulta se demora mucho mas que antes |
Previous Message | Miguel | 2006-03-31 19:25:41 | Re: consulta se demora mucho mas que antes |