Re: Problema uso de indices...

> ¿Qué pasa si le das un SET enable_seqscan TO off en el server 1?
Ya habia hecho pruebas con el parametro enable_seqscan y ni asi me
tomo en cuenta el indice, sigue haciendo lo mismo

Ahora lo que paso recientemente es que el dia de hoy el server2 dejo
de usar el indice al igual que el server 1.. y cuando hice pruebas en
el explain analyze vi esto entre parentesis (never executed) al final
de la lines del indice, no se a que se deba esto. El explain fue el
siguiente:

explain analyze select * from datosentrada_his where fechacreacion
between '07/12/2011 05:00' and '07/13/2011 04:59' and (flota='hesa'
and unitno='9014');

QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Result (cost=4932.34..5988.53 rows=265 width=600) (actual
time=27.099..27.099 rows=0 loops=1)
-> Append (cost=4932.34..5988.53 rows=265 width=600) (actual
time=27.095..27.095 rows=0 loops=1)
-> Bitmap Heap Scan on datosentrada_his
(cost=4932.34..5988.53 rows=265 width=600) (actual time=27.093..27.093
rows=0 loops=1)
Recheck Cond: (((unitno)::text = '9014'::text) AND
((flota)::text = 'hesa'::text) AND (fechacreacion >= '2011-07-12
05:00:00'::timestamp without time zone) AND (fechacreacion <=
'2011-07-13 04:59:00'::timestamp without time zone))
-> BitmapAnd (cost=4932.34..4932.34 rows=265 width=0)
(actual time=27.089..27.089 rows=0 loops=1)
-> Bitmap Index Scan on fki_vehiculo_his
(cost=0.00..1403.11 rows=54548 width=0) (actual time=27.086..27.086
rows=0 loops=1)
Index Cond: (((unitno)::text =
'9014'::text) AND ((flota)::text = 'hesa'::text))
-> Bitmap Index Scan on ind_fecha
(cost=0.00..3528.85 rows=168081 width=0) (never executed)
Index Cond: ((fechacreacion >= '2011-07-12
05:00:00'::timestamp without time zone) AND (fechacreacion <=
'2011-07-13 04:59:00'::timestamp without time zone))
Total runtime: 27.214 ms
(10 rows)

> Debería cambiar al segundo plan. Si es así, creo que lo que deberías
> hacer es
>
> 1. incrementar effective_cache_size
> 2. incrementar cpu_tuple_cost y/o cpu_operator_cost
>

El effective_cache_size lo tengo a 3/4 de mi memoria ram no se si sea
recomendable aumentarlo mas. Los otros 2 parametros no los he movido
hare pruebas a ver que pasa.

Entre mis pruebas hice un indice con los 3 campos involucrados en la
consulta y aunque postgres deberia tomar el indice1 donde estan los 2
primeros campos y el indice2 donde esta la fecha. Al crear este nuevo
indice ya esta funcionando mejor la consulta pero creo que ya son
demasiados indices sobre una tabla.. y los 2 primeros indices si se
estan usando espero no me afecte el desempeño tanto indice, ustedes
que creen?. Saludos y muchas gracias por sus comentarios y ayuda.

Roberto Campos

> --
> Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
>