Re: Ayuda Consulta de fechas

Disculpen el reenvio, pero ya no recibi respuesta y no se si llego el
correo, solo lo reenviare esta vez por si las dudas.

Entre tanto les comento que probe la consulta en otra tabla con menos
campos pero igual mas de (50 millones de registros)... en la cual no
tengo ningun campo en nulo (pos si afectaba). y pasa exactamente lo
mismo, hago la consulta con fechas entre 1 mes.. y tarda demasiado
tiempo en traer datos ( mas de 5 minutos), pense que solo era en
fechas pero tambien pasa en el id de la tabla ( importacionid) , se
que postgresql soporta bases de datos mucho mas grandes a la que estoy
manejando y supongo debe haber una forma de hacer mas rapidas estas
consultas. De verdad necesito su ayuda ya que yo recomende ampliamente
postgresql y ya me estan diciendo que debi seleccionar otro manejador
de BD (llegue al proyecto como consultor y desarrollador de sistemas
embebidos y ahora soy el DBA entre otras cosas). Saludos.

Roberto Campos

P.D. Ya comence con pruebas de particionamiento y aunque apenas llevo
2 particiones no he notado mejoria en la consulta que les presente.
Aunque si en otro tipo de consultas que no requieren agrupación.

El día 22 de julio de 2011 20:41, motum hesa <motums(at)gmail(dot)com> escribió:
> Alvaro una disculpa quise editar la consulta para que se viera mas
> rapido el tipo de campo.. pero ahora que les mande la estructura pues
> ya no es necesario
>
>
>>Hmm, aquí no hay ninguna columna "idtbl".  Por favor muestra la consulta
>>y el explain analyze con los nombres correctos de las columnas, sin
>>editorialización.
>
> Esta es la consulta original, ahorita cambio el tiempo que muestra el
> explain debido a las fechas por las que voy.
>
>
> select     max(importacionid), min(importacionid),
>        unitno, flota
>        from     datosentrada_his
>        where     fechacreacion BETWEEN '2011-06-01 00:00:00' and '2011-07-01
> 23:59:59'
>        group by unitno,flota order by unitno
>
>        "Sort  (cost=969443.39..969445.32 rows=775 width=18)"
> "  Sort Key: unitno"
> "  ->  HashAggregate  (cost=969394.57..969406.19 rows=775 width=18)"
> "        ->  Index Scan using ind_fecha on datosentrada_his
> (cost=0.00..925042.61 rows=4435196 width=18)"
> "              Index Cond: ((fechacreacion >= '2011-06-01
> 00:00:00'::timestamp without time zone) AND (fechacreacion <=
> '2011-07-01 23:59:59'::timestamp without time zone))"
>
>
>
>
>
> El día 22 de julio de 2011 18:08, Jaime Casanova
> <jaime(at)2ndquadrant(dot)com> escribió:
>> On Fri, Jul 22, 2011 at 5:16 PM, motum hesa <motums(at)gmail(dot)com> wrote:
>>>
>>> Table "public.datosentrada_his"
>>>       Column        |            Type             | Modifiers
>>> ---------------------+-----------------------------+-----------
>>
>> aunque no es lo que preguntaste, te dire que tanto campo que acepta
>> NULL me huele a mal diseño (especialmente porque hay campos que
>> obviamente estan relacionados entre si de forma especial
>>
>
> Hola Jaime, gracias por el comentario, efectivamente el sistema tenia
> un mal diseño de base de datos cuando lo tome, yo he tratado de
> mejorarlo con indices, llaves primarias y foraneas en donde debe ser,
> trato de evitar la insercción de nullos en los campos que viste pero
> no he cambiado la estructura, si es recomendable hoy mismo lo hago en
> los campos que ya estoy seguro que no hay nullos...
>
>
>> --
>> Jaime Casanova         www.2ndQuadrant.com
>> Professional PostgreSQL: Soporte 24x7 y capacitación
>>
>
>>Alvaro Herrera
>>Sí, hay varias cosas que son sospechosas en este diseño ... pareciera
>>una tabla donde se almacenan detalles crudos (posición geográfica en un
>>momento determinado) junto con detalles cocinados (análisis a partir de
>>la historia del movimiento del vehículo).  Eso deberías evitarlo, porque
>>crea todo tipo de problemas.
>
>
> de hecho todo esos datos ya fueron procesados y son guardados como
> historicos en esta tabla. Aunque si me puedes decir algun tipo de
> problemas que tu consideres se presente en este diseño de tabla lo
> tomare en cuenta para una posible reestructuracion...
>
>
> Saludos y gracias por sus consejos, siempre son bienvenidos...
>
>
>
> Roberto Campos
>