Re: es posible acelerar un update?

Este es el Explain:

explain analyze update arc_cuotas set cuo_pagado = ( select sum(pag_08
+ pag_09) from arc_ pagos where
arc_pagos.pag_01 = arc_cuotas.cuo_01 and arc_pagos.pag_02 =
arc_cuotas.cuo_02 ), cuo_pagad o_mora
= ( select sum(pag_10) from arc_pagos where arc_pagos.pag_01 =
arc_cuotas.cuo_01 and arc_pagos.
pag_02 = arc_cuotas.cuo_02 ) where cuo_estado not in ('C','A');

QUERY PLAN
------------------------------------------------------------------------------------------------------

--------------------------------------------------------
Seq Scan on arc_cuotas (cost=0.00..2406095.23 rows=197961 width=202)
(actual time=0.183..116982.109
rows=198249 loops=1)
Filter: ((cuo_estado <> 'C'::bpchar) AND (cuo_estado <> 'A'::bpchar))
SubPlan
-> Aggregate (cost=5.98..5.99 rows=1 width=9) (actual
time=0.025..0.025 rows=1 loops=198249)
-> Index Scan using ts_idx_arc_pagos_pag_01_pag_02 on
arc_pagos (cost=0.00..5.97 rows=1 w
idth=9) (actual time=0.022..0.022 rows=0 loops=198249)
Index Cond: (((pag_01)::text = ($0)::text) AND (pag_02 = $1))
-> Aggregate (cost=5.98..5.99 rows=1 width=22) (actual
time=0.298..0.299 rows=1 loops=198249)
-> Index Scan using ts_idx_arc_pagos_pag_01_pag_02 on
arc_pagos (cost=0.00..5.97 rows=1 w
idth=22) (actual time=0.294..0.294 rows=0 loops=198249)
Index Cond: (((pag_01)::text = ($0)::text) AND (pag_02 = $1))
Trigger for constraint fk_01: time=683.149 calls=131
Total runtime: 1292483.767 ms
(11 rows)

De inicio uno podría pensar que los selects internos son los que me
consumen mucho tiempo, es cierto que consumen pero miren este mismo
explain solo haciendo update sobre 2 columnas sin los querys internos:

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

2008/1/29, Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Ernesto Quiñones escribió:
> > Hola Alvaro, justo para descartar que sea e procedido a eliminar mis
> > FK y ver si por ahi esta el problema, y no va por ese lado, demora tan
> > igual con ella que isn ellas (con ellas seguro demorara un poco mas)
> >
> > tengo 6 indices en esa tabla, no son demasiado grandes, solo 1 o 2
> > columnas...podria ser eso?
>
> Hmm, si, cada indice agrega un sobrecosto adicional al update. Si la
> porcion de la tabla que va a actualizar es muy grande, podrias intentar
>
> begin;
> drop index ...
> drop index ...
> drop index ...
> update ...
> create index ...
> commit;
>
>
> > estuve probando haciendo el update sobre la misma tabla pero con solo
> > 500 registros que tenian un valor especifico y fue casi inmediato,
> > pero el otro update que tiene hace los 180k registros es el que demora
> > infinidad
>
> Muestra el EXPLAIN ANALYZE del update.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> PostgreSQL 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.