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

2009/8/27 Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>

> 2009/8/26 Sebastian Machuca <serroba(at)gmail(dot)com>:
> >
> > No tengo expertiz en el tema, pero yo asumo que un indice ayuda, porque
> si
> > es un arbol binario y balanceado, los datos deben estar ordenados,
>
> el indice esta ordenado
>
> > y buscar
> > los distintos, si son solo 2, debería desde mi punto de vista ser muy
> > rápido
> >
>
> "tu" sabes que son solo 2... postgres no, la unica forma que tiene de
> saber cuantos valores distintos hay es visitar todos los registros del
> indice y agregar al conjunto de resultados al menos el primero cada
> vez que encuentre un valor nuevo... el problema es que no solo puede
> agregarlo al conjunto de resultados sino que debido a las reglas del
> MVCC es posible que ese registro ya hubiera sido borrado asi que antes
> debe chequear en la tabla si realmente el regsitro aun es valido...
>

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?

>
> lo que implica que vistaras todo el indice, y dependiendo de la
> distribucion en la tabla y la cantidad de tuplas muertas quiza tambien
> algunas paginas de la tabla...
>
> tengo la sospecha de que tanto work_mem te hace mas dano que bien...
> que pasa si ejecutas "set enable_indexscan to off;" antes de la
> consulta?
>

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.

>
> de todos modos en 8.3 es mejor la forma "select ani from trx_8 group by
> ani;"
>
> --
> Atentamente,
> Jaime Casanova
> Soporte y capacitación de PostgreSQL
> Asesoría y desarrollo de sistemas
> Guayaquil - Ecuador
> Cel. +59387171157
>

--
Sebastian Machuca
Estudiante Ingeniería Civil en Computación
+56 9 77449117
Sent from San Miguel, RM, Chile