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
<ja...@2ndquadrant.com> escribió:
> On Fri, Jul 22, 2011 at 5:16 PM, motum hesa <mot...@gmail.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
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
