2009/8/27 Jaime Casanova <jcasa...@systemguards.com.ec> > 2009/8/26 Sebastian Machuca <serr...@gmail.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
