El 27/07/11, Alvaro Herrera <[email protected]> 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 <[email protected]> > 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 - Enviado a la lista de correo pgsql-es-ayuda ([email protected]) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
