Re: es posible acelerar un update?

no pude mas con la duda, a pesar de que ya es media noche, si eran los
indices, luego que los elimine este es el resultado

explain analyze update arc_cuotas set cuo_pagado = 0, cuo_pagado_mora
= 0 where cuo_estado not in ('C','A');
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------
Seq Scan on arc_cuotas (cost=0.00..20574.28 rows=199258 width=202)
(actual time=356.297..4946.592 rows=191299 loops=1)
Filter: (cuo_estado <> ALL ('{C,A}'::bpchar[]))
Total runtime: 33503.188 ms

es notable como consume en tiempo de update, uno de estos campos
actualizados era parte de un indice, sin embargo primero borre ese
indice y el tiempo de demora continuaba siendo alto, luego que elimine
todos los otros mejoro mucho

gracias por la ayuda, ahora empezare a revisar cual indice
especificamente es el que se estaba atorando

saludos

2008/1/29, Ernesto Quiñones <ernestoq(at)gmail(dot)com>:
> voy a hacer la prueba y les cuento, temporalmente tuve que cambiar mi
> función y aplicar otra técnica mas larga pero que hace que el query
> que se tomaba entre 12 a 15 minutos en procesar bajara a segundos,
> pero igual me queda el bichito porque una demora tan larga....
>
> saludos
>
> 2008/1/29, Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> > Ernesto Quiñones escribió:
> >
> > > explain analyze update arc_cuotas set cuo_pagado = 0, cuo_pagado_mora
> > > = 0 where cuo_estado not in ('C','A');
> > > QUERY PLAN
> > > ------------------------------------------------------------------------------------------------------------------------
> > > Seq Scan on arc_cuotas (cost=0.00..17124.30 rows=192822 width=201)
> > > (actual time=0.057..34207.650 rows=110930 loops=1)
> > > Filter: (cuo_estado <> ALL ('{C,A}'::bpchar[]))
> > > Total runtime: 625348.684 ms
> > > (3 filas)
> > >
> > >
> > > y este es el explain aplicado solo a pocos registros:
> > >
> > > explain analyze update arc_cuotas set cuo_pagado = 0, cuo_pagado_mora
> > > = 0 where cuo_estado in ('A');
> > > QUERY PLAN
> > > --------------------------------------------------------------------------------------------------------------------------------------
> > > Index Scan using ts_idx_cuotas2 on arc_cuotas (cost=0.00..941.78
> > > rows=493 width=202) (actual time=15.006..129.776 rows=841 loops=1)
> > > Index Cond: (cuo_estado = 'A'::bpchar)
> > > Total runtime: 1288.670 ms
> >
> > Hmm, si, es bien posible que sean los indices los que hacen lento el
> > UPDATE. ¿Mediste botando los indices antes de hacer el update?
> >
> > Aca un experimento rapido me confirma que una tabla con 4 indices toma
> > el doble de tiempo en un UPDATE masivo que si tiene solo 2, lo cual toma
> > el doble que si no tiene ninguno. (Los valores no son muy confiables
> > porque estoy en mi laptop que baja y sube la velocidad de la CPU
> > dinamicamente).
> >
> > Si tienes la posibilidad de bloquear la tabla hasta haber completado el
> > update, esto puede ser lo mas conveniente.
> >
> > --
> > Alvaro Herrera http://www.CommandPrompt.com/
> > lPostgreSQL Replication, Consulting, Custom Development, 24x7 support
> >
>
>
> --
> Inscribete en las listas de APESOL
> http://listas.apesol.org/mailman/listinfo
>
> Visita
> http://www.eqsoft.net
> Manuales, noticias, foros, etc.
>

--
Inscribete en las listas de APESOL
http://listas.apesol.org/mailman/listinfo

Visita
http://www.eqsoft.net
Manuales, noticias, foros, etc.