Re: Ayuda Consulta de fechas

El 27/07/11, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> escribió:
> Excerpts from motum hesa's message of mar jul 26 19:36:37 -0400 2011:
>
>
> 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.

Borre el indice he hice pruebas, si se usaba ese indice asi que lo
tuve que crear otra vez, aunque con eso me di cuenta que el otro
indice que incluia la fecha al parecer no me sirve, lo elimine y no vi
cambios hasta el momento. De todas maneras seguire checando por
cualquier cosa.

>
>
> 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).
>

La columna viajeactivo es una referencia a otra tabla, lo por lo que
me di cuenta que me hace falta una llave foranea ahi, ya lo platique
con los programadores ya que esto les pega y en la primera oportunidad
lo hago.

Como son demasiados registros tarda mucho cambiar las columnas pero ya
estoy agregando la propiedad "NOT NULL" a la mayoria de los campos.
Aunque parece que voy a tardar un buen rato.

>
> Sí, mi hipótesis es que eso debería ayudar en el group by.
>
No ayudo el indice que me dijiste para el Group by.

>
> 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á:
>

Leyendo el codigo entendi todo lo que me decias y pues cambie la
consulta a que se consulte cada unidad por separado en vez de todas
las unidades, con eso quite el group by y use el limit y por cada
unidad tarda algunos milisegundos.. haciendo cuentas cada flota tiene
aprox 100 unidades multiplicando esto por los milisegundos que tarda
cada unidad resulta mas rapido hacer un ciclo en programación que
consulte cada unidad de la flota.. por lo que se harian 100 consulta
con el limit 1... Aqui el indice que sugeriste ayudo bastante. Muchas
gracias.

>
> (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).

Para opciones de repliacion planeadas mas adelante voy a pasarme a la
version 9 de postgres ( ahorita estoy en la 8.4), crees que ayude
tambien a las consultas?

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

Muchas gracias por todos tus comentarios Álvaro ayudaron bastate a
resolver dudas y mejorar mi tabla. Felicitaciones a los programadores
el codigo esta muy explicito y excelentemente bien comentado.

Para la Lista mi solucion sera cambiar de una Consulta sobre todos los
registros con Group by a varias consultas pequeñas y rapidas por
unidad sin group by.

Saludos

Roberto Campos