Re: Ayuda Consulta de fechas

Excerpts from motum hesa's message of mar jul 26 19:36:37 -0400 2011:

> > El índice ind_fecha es redundante con inf_fecha_id_his.  A menos que se
> > uso mucho, te sugiero borrarlo también.  Hago notar que un índice se
> > puede recorrer en ambas direcciones, así que tener uno ASC y uno DESC no
> > aporta en nada.  Te sugiero borrar ind_fecha.
>
> Si tengo muchas consultas solo por la fecha, buscando pues uso menos
> el segundo indice el cual pues intentare borrar para ver que pasa. de
> hecho casi siempre busco una fecha para obtener el valor del campo
> importacionid

Ojo que si usas mucho el campo fecha por separado y buscas por rangos de
fechas, puede que no te resulte bueno eliminar ese índice. La razón es
que un índice de múltiples columnas es más pesado que uno de una sola
columna (obvio). Me ha tocado ver casos en los que existían ambos
índices (uno con la columna sola y otro con dos columnas), se borró el
de la columna sola, y resultó que era tan utilizado antes de borrarse
que el sistema se puso mucho más lento.

Así que te sugiero que si vas a hacer esto, le pongas atención al
sistema para ver si es verdad que mejora al borrar el índice.

> > El índice fki_viajeactivo_his suena bastante sospechoso, pero habría que
> > saber qué hace el campo viajeactivo antes de dar una opinión.
>
> El campo viajeactivo, hace referencia a otra tabla que es donde se
> guardan los viajes realizados por una unidad por ejemplo, salio de
> base tal dia con tales valores y regreso tal dia con tales valores, en
> la tabla en cuestion "datosentrada_his" se hace referencia a
> viajeactivo en el momento que llegaron los datos para cuando se quiera
> hacer el analisis del viaje o si se quiere hacer un analisis solo por
> fecha.

Hmm. Honestamente suena a que el campo debería eliminarse
completamente :-) Quizás esta propiedad debería almacenarse en otra
tabla, si es que realmente es necesario almacenarla.

A todo esto, a veces cuando tienes campos que tienen muchos valores
nulos, te puede convenir crear un índice de esta forma:

create index fff on tutabla (viajeactivo) WHERE viajeactivo IS NOT NULL;

Haciéndolo así ahorras espacio en el índice y no pierdes ninguna
funcionalidad (a menos que hagas búsquedas WHERE viajeactivo IS NULL).

> > Para mejorar esta consulta creo que deberías tener un índice en
> > (unitno, flota, fechacreacion).  Agrégalo y prueba de nuevo la consulta
> > a ver si lo usa.
>
> Voy a crear el indice que mencionas aunque precisamente las consultas
> lentas no incluyen unidad, pero es posible que ayude con el group asi
> k lo hare hoy en la noche. gracias nuevamente.

Sí, mi hipótesis es que eso debería ayudar en el group by.

> Mientras tanto te comento que las consultas mas lentas son donde uso
> las funciones MAX y MIN... el indice que me comentas ayudara... o
> tienes alguna recomendacion mas para usar este tipo de funciones. ?

Lo que te puedo decir es que el optimizador sabe convertir MIN() y MAX()
en un indexscan con LIMIT 1 internamente, pero estos trucos sólo se
pueden aplicar en situaciones limitadas. [leyendo código] En
particular, por lo que veo en el código, no se pueden aplicar cuando
tienes GROUP BY ... así que olvida lo que dije de ese índice, porque es
obvio que no te va a servir.

Puedes mirar el código fuente (con bastantes comentarios que explican lo
que puede y lo que no puede hacer) acá:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/optimizer/plan/planagg.c;h=369ed9c929c89f74c5df0c227d12c565c0f58017;hb=REL9_0_STABLE#l58

(Este es el de 9.0. Si estás usando otra versión tendrás que buscar el
mismo archivo a partir de otro HEAD).

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