RE: El indice no mejora me mejora el rendimiento de mis consultas.

> -----Mensaje original-----
> De: Sebastian Machuca
>
> Para que me sirve el indice entonces. Probablemente tengo mal
> el concepto de indice, porque yo tenia entendido que si tengo
> el asunto indexado, y hago una consulta sobre solo una
> columna que efectivamente esta indexada, yo asumí que el
> distinct, o el group by debería ejecutarse sobre el indice y
> después arrojar los resultados obtenidos y en ese caso, desde
> lo que yo pensaba, como el indice solo tiene 2 valores
> distintos, debería ser muy rápido.
>
>
> Me podrían aclarar ese punto?
>

El índice es una herramienta para hacer búsquedas aleatorias rápidamente, es
decir, conocer donde se encuentra almacenado cierto dato sin tener que
recorrer todos los datos del archivo uno por uno.

Un ejemplo muy esquemático:
Si el archivo "animales" contiene lo siguiente:

Animal
------
zorro
gato
perro
caballo
gallo
gato
zorro

Un índice sobre Animal tendría lo siguiente:

caballo:4
gallo:5
gato:2
gato:6
perro:3
zorro:1
zorro:7

donde el : separa el nombre de la fila donde se ubica en el archivo.

Fijate que en el índice hay tantas entradas como en el archivo original. Si
tuvieras que saber cuantos animales distintos hay en el archivo sea que
entres por índice o no, tienes que recorrer los 7 registros. Para este tipo
de consulta el índice no tiene más ventajas que presentarte los datos ya
ordenados.

Pero si quisieras buscar únicamente "zorro" gracias al índice que te
presenta los datos ordenados podrás aplicar un algoritmo de búsqueda para
obtener rápidamente las entradas existentes:
zorro:1
zorro:7

Con esto sabrías que en tu archivo de datos hay entradas para "zorro" en las
filas 1 y 7. Ahora puedes leer directamente esos 2 registros sin necesidad
de barrer todo el archivo.

Una ventaja importante es que los índices son por lo general más chicos que
el archivo original, entonces leerás menos información del disco (suponte
que el archivo de datos además del nombre contiene todas las características
de los animales, descripción y una foto). Entonces es probable que la
información del índice quepa completamente en memoria con lo cual además te
evitas toda lectura en disco.

>
> Por que tanto work_mem puede hacer dano?? En resultados
> empiricos, al aumentar la memoria a 512 reduje tiempos de
> varios minutos a 50 segundos. De ese modo en ves de hacer
> pagging al momento de hacer el sort, lo hacia completo en
> memoria con un quicksort. El valor 512 lo estableci mas o
> menos empiricamente. Probe con 256, 350 y al final con 512, y
> con ese valor logre un quicksort completo en memoria. Claro
> que era para otra pregunta completamente diferente a esta, en
> la que se realizan 4 INNER JOIN con otra tablas, algunos
> GROUP BY, pero no es la pregunta que estoy con intriga en
> estos momentos.
>
>

work_mem define el maximo de memoria que puede utilizar una operación sort.
Algunas consultas complejas pueden implicar múltiples sort y cada una de
ellos ocupar <work_mem> en memoria. Un work_mem demasiado alto puede
llevarte a que un único query consuma toda la memoria física disponible y
ponga de rodillas tu sistema.

No estoy seguro Para un índice de 350.000 datos integer, un work_mem = 8MB
debiera ser más que suficiente para resolverlo en memoria.

Lo que se recomienda es mantener work_mem configurado en valores razonables
(entre 1 y 16MB) y luego ante las consultas que requieran un extra
modificarlo puntualmente para esa sesión mediante el comando:

set work_mem = xxxMB;

justo antes de ejecutar el query en cuestión.

Claro que en un sistema monousuario o donde tienes certeza de qué tipo de
consultas se ejecutan puedes configurar work_mem a tu conveniencia
particular.

Saludos,
Fernando.