Re: usando indices => 100 veces mas lento (!)

Wow!

Esto es sorprendente. Déjame reproducir tu caso, y si algo
nuevo surge te informo. Gracias por el juguetito, Hernán.

Saludos.

Hernan Gonzalez wrote:
>
> Un caso un poco raro (pero nada 'patologico', me
> sucedio la semana pasada).
>
> Tenemos dos tablas muy sencillitas A y B :
>
> A
> ---------
> A1 int2
>
> B
> ----------
> B1 int2
> BA oid <--- esto es clave externa, apunta a A.oid
>
> Todos lo campos (tambien los oids) estan indexados (como hash).
> Cada tabla tiene 1000 registros, y para cada registro de
> la tabla A hay exactamente un registro de la tabla B que
> lo apunta.
> De modo que la consulta
>
> [consulta 1]
>
> SELECT COUNT(*) FROM A, B WHERE B.BA = A.oid;
>
> devuelve = 1000.
>
> La consulta es muy sencilla, y es practicamente instantanea
> (digamos, algunas decimas de segundo) (tengo una PII 300Mhz,
> 64 Mb ram, Linux-RedHat 5.1, postgres 6.3.2).
>
> Ahora, hacemos todos los campos A1=0 y B1= 0,
> (si, todos igual ... supongan que es un flag o
> algo asi)....
> despues un 'vacuum' (por las dudas) y consultamos:
>
> [consulta 2]
>
> SELECT COUNT(*) FROM A, B
> WHERE B.BA = A.oid
> AND A.A1 = 0 ;
>
> Lo mismo: 1000 registros encontrados, en menos de un segundo.
> Pero (ahora viene lo interesante, no se impacienten) hagamos
> algo apenas mas complicado:
>
> [consulta 3]
>
> SELECT COUNT(*) FROM A, B
> WHERE
> B.BA = A.oid
> AND A.A1 = 0
> AND B.B1 = 0;
>
> Tambien devuelve 1000 registros.. pero demora 100 veces mas!!!
> (alrededor de un minuto !).
> Y si en lugar de tener 1000 registros tenemos 3000 (como sucedia en
> mi caso real, del cual esto es una simplificacion) la consulta
> demora .... una eternidad (nunca tuve la paciencia de esperar a
> que termine).
>
> Que esta pasando ??
> Perdi un dia entero con este problema, y conclui que
> el problema es que el indice no deberia usarse cuando todos
> los campos valen lo mismo. (!)
> Si hacemos un drop de los indices A1 y/o A2, la consulta es
> instantanea.
> No altera cambiar el indice de hash a btree.
>
> Alguien puede explicarme (o corregirme) ?
> (tengo poca experiencia en bases de datos).
>
> Suena plausible que un indice se comporte mal cuando
> todos (o casi) los campos valen lo mismo... pero no
> me deja muy tranquilo... yo no se (supuestamente) a
> priori la distribucion de los valores de los
> campos A1 - B1. No me digan que la moraleja es
> 'no usar indices' ! :-)
> No tiene el Postgres la inteligencia
> necesaria para optimizar la consulta ?
>
> La respuesta (y moraleja) provisoria que encontre es esta:
>
> VACUUM ANALYZE !!!!!!!!!!!!!!!!!!!!
>
> Parece que la opcion 'analyze' hace que el vacuum
> revise la distribucion de los valores; despues
> de hacerlo, la consulta anda bien: aunque tiene
> indices definidos decide no usarlos y la consulta
> es instantanea.
>
> Me quedan dudas...
> No se por que la [consulta 2] no tiene el problema
> y la 3 si... ni por que no logre reproducir el
> problema usando una unica tabla ...
>
> Saludos
>
> Hernan Gonzalez
> Buenos Aires, Argentina
> hgonzal(at)sinectis(dot)com(dot)ar
> --------- Pie de mensaje -------------------------------------------
> Archivo historico: http://tlali.iztacala.unam.mx/maillist/pgsql-ayuda
> Cancelar inscripcion:
> mail to: majordomo(at)tlali(dot)iztacala(dot)unam(dot)mx
> text : cancelacion pgsql-ayuda

--
"Create like a god, Bruno Unna <bruno(at)iac(dot)com(dot)mx>
command like a king, Desarrollo de Software
and work like a slave." Internet de Alta Calidad
Kawasaki PGP public key available
--------- Pie de mensaje -------------------------------------------
Archivo historico: http://tlali.iztacala.unam.mx/maillist/pgsql-ayuda
Cancelar inscripcion:
mail to: majordomo(at)tlali(dot)iztacala(dot)unam(dot)mx
text : cancelacion pgsql-ayuda