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

El 26 de agosto de 2009 18:49, Sebastian Machuca<serroba(at)gmail(dot)com> escribió:
> Hola a todos.
>
> La situación es la siguiente. Tengo una tabla (trx_8) con unos 350.000
> registros.
>
> Quiero realizar una consulta sobre una única columna, llamada ani, que es de
> tipo bigint.
>
> En el caso en particular al que me enfrento, he creado un indice usando un
> árbol binario de la siguiente manera
>
> CREATE INDEX ani_8 ON trx_8 using BTREE (ani);
>
> Las consultas que he realizado son las siguientes:
>
> EXPLAIN ANALYZE SELECT distinct ani from trx_8;
>                                                             QUERY PLAN
> -----------------------------------------------------------------------------------------------------------------------------------
>  Unique  (cost=0.00..21207.47 rows=2 width=8) (actual time=0.035..1395.262
> rows=2 loops=1)
>    ->  Index Scan using ani_8 on trx_8  (cost=0.00..20317.76 rows=355883
> width=8) (actual time=0.030..694.861 rows=355883 loops=1)
>  Total runtime: 1395.313 ms
> (3 rows)
>
> y
>
> EXPLAIN ANALYZE SELECT  ani from trx_8 group by ani;
>                                                             QUERY PLAN
> -----------------------------------------------------------------------------------------------------------------------------------
>  Group  (cost=0.00..21207.47 rows=2 width=8) (actual time=0.034..1425.076
> rows=2 loops=1)
>    ->  Index Scan using ani_8 on trx_8  (cost=0.00..20317.76 rows=355883
> width=8) (actual time=0.030..759.136 rows=355883 loops=1)
>  Total runtime: 1425.135 ms
> (3 rows)
>
>

Tiraste un 'analyze' a la base? el estado del indice? (existe una aplicación del
contribg pg_stattuple que verifica el estado de estos objetos...

No se si es un esquema realmente bueno ese de tener un indice para un campo
que no tiene tantos valores distintos, de hecho no creo que sea lo más
conveniente.

Yo lo haria de una manera más radical...
select unnest(most_common_vals::text::int[]) from pg_stats where
tablename ~ 'tx8';

Gracias a esto, descubri un comportamiento raro del unnest
específicamente con anyarray
de es enteros (funcina sin casteo para most_common_freqs).

Dentro de pg_Stats, tenés un campo (n_distinct) que te informa que
tantos campos distintos
tenés.

Ej:
create table pipi as select round(random()) from generate_series(1,1000) ;

Quedarían 2 valores distintos entre 1000. el most_common_freqs te va a
informar las frecuencias
de esos valores.

Recorda que para esto ultimo tenes que tener las estadisticas actualizadas, no
se si es realmente conveniente hasta cierto punto...

Espero que te sirva...

--
Emanuel Calvo Franco
DBA at: www.siu.edu.ar
www.emanuelcalvofranco.com.ar