Skip site navigation (1) Skip section navigation (2)

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

From: Sebastian Machuca <serroba(at)gmail(dot)com>
To: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: El indice no mejora me mejora el rendimiento de mis consultas.
Date: 2009-08-27 13:14:35
Message-ID: 5403e68d0908270614w16d480a2i550fb0f11b37209b@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
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

In response to

Responses

pgsql-es-ayuda by date

Next:From: Alvaro HerreraDate: 2009-08-27 13:54:56
Subject: Re: El indice no mejora me mejora el rendimiento de mis consultas.
Previous:From: Emanuel Calvo FrancoDate: 2009-08-27 12:48:18
Subject: Re: El indice no mejora me mejora el rendimiento de mis consultas.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group