Pues muchas gracias a todos y principalmente a Alvaro, La solución a
esta cuestión es crear indices multicolumna donde sean necesarios.
Espero le sirva a alguien esto. Saludos.
Roberto Campos
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción
Excerpts from motum hesa's message of vie sep 02 01:26:01 -0300 2011:
> >
> > Uh, después de mirarlo otra vez, es obvio que hace lo mismo porque en el
> > plan no hay ningún seqscan, sino un indexscan. Prueba poniendo
> > enable_indexscan TO off. Esto debería hacer que empiece a usar el
> > bitma
>
> Uh, después de mirarlo otra vez, es obvio que hace lo mismo porque en el
> plan no hay ningún seqscan, sino un indexscan. Prueba poniendo
> enable_indexscan TO off. Esto debería hacer que empiece a usar el
> bitmapscan que es el plan rápido.
>
Definitivamente uso ahora un bitmapscan y aunqu
Excerpts from motum hesa's message of mar ago 30 23:24:49 -0300 2011:
> > ¿Qué pasa si le das un SET enable_seqscan TO off en el server 1?
> Ya habia hecho pruebas con el parametro enable_seqscan y ni asi me
> tomo en cuenta el indice, sigue haciendo lo mismo
Uh, después de mirarlo otra vez, es ob
> Hm, raro. Muestra el \d de la tabla otra vez por favor, en ambos
> servidores. Muestra también el resultado de
>
Server 1
Table "public.datosentrada_his"
Column|Type | Modifiers
-+-+-
Excerpts from motum hesa's message of mar ago 30 23:24:49 -0300 2011:
> > ¿Qué pasa si le das un SET enable_seqscan TO off en el server 1?
> Ya habia hecho pruebas con el parametro enable_seqscan y ni asi me
> tomo en cuenta el indice, sigue haciendo lo mismo
Hm, raro. Muestra el \d de la tabla ot
> ¿Qué pasa si le das un SET enable_seqscan TO off en el server 1?
Ya habia hecho pruebas con el parametro enable_seqscan y ni asi me
tomo en cuenta el indice, sigue haciendo lo mismo
Ahora lo que paso recientemente es que el dia de hoy el server2 dejo
de usar el indice al igual que el server 1.
Excerpts from motum hesa's message of mar ago 30 15:38:38 -0300 2011:
Hmm,
> Server1
> -> Index Scan using fki_vehiculo_his on datosentrada_his
> (cost=0.00..697.42 rows=2 width=600) (actual
> time=80568.991..173356.094 rows=2865 loops=1)
>Index Cond: (((unitno)::text =
Aqui esta solo el explain analyze de la seccion que comentaba alvaro,
que justamente donde esta el problema:
Server1
# explain analyze select * from datosentrada_his where unitno='142'
and flota='Transportes Bueno' and fechacreacion between '07/13/2011
05:00' and '07/15/2011 04:59';
QUER
Este es el resultado del explain analyze en el server 1:
QUERY PLAN
-
Sort (cost=1718.18..1718.21
Excerpts from motum hesa's message of mar ago 30 15:08:53 -0300 2011:
> Hola disculpen la molestia nuevamente, he estado tratando de optimizar
Hola, por favor manda el explain analyze de la subconsulta en ambos
servidores:
> select * from datosentrada_his where unitno='111' and
> flota='EMPRESA1'
Roberto
Podria ser como mencionas la degradacion del raid.
si es linux
si es por software (el raid)
entonces
cat /proc/mdstat
si en alguno te tira un _U quiere decir que una unidad esta caida
se puede cambiar con raid10 y se recupera-
salu2
mdc
2011/8/30 motum hesa
Hola disculpen la molestia nuevamente, he estado tratando de optimizar
una consulta que ya habia optimizado pero el cliente me aviso que
estaba tardando demasiado, lo raro de el caso es que la misma base de
datos la respalde y la desplegue un par de semanas atras en un
servidor de pruebas, donde se
13 matches
Mail list logo
