Re: es posible acelerar un update?

Hola amigos
tengo una tabla de 250k registros, tengo que correrle un update de mas
o menos 180k registros, el problema es que esta tomando bastante
tiempo, a veces mas de 15minutos, la tabla pasa por vacumm
continuamente y no tiene deletes solo procedimientos de insert diarios
que suben algo de 1000 registros nuevos diariamente

es posible mejorar ese tiempo en el update? a lo mejor bloqueando la
tabla o algo así?, esta tabla solo es consultada por un par de
personas que facilmente pueden esperar el fin del proceso de update de
la tabla

alguna idea que me pueda ayudar?

saludos

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

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

Ernesto Quiñones escribió:
> Hola amigos
> tengo una tabla de 250k registros, tengo que correrle un update de mas
> o menos 180k registros, el problema es que esta tomando bastante
> tiempo, a veces mas de 15minutos, la tabla pasa por vacumm
> continuamente y no tiene deletes solo procedimientos de insert diarios
> que suben algo de 1000 registros nuevos diariamente

Hmm, 250k registros deberian actualizarse mucho mas rapido que eso.

alvherre=# create table foo (a int);
CREATE TABLE
alvherre=# insert into foo select * from generate_series(1, 250000);
INSERT 0 250000
alvherre=# \timing
Mostrar tiempos está activado.
alvherre=# update foo set a = a + 1;
UPDATE 250000
Duración: 3518,455 ms
alvherre=# vacuum foo;
VACUUM
Duración: 281,051 ms

Quizas tu problema tiene que ver con chequeos de FKs. ¿Tiene alguna FK
la tabla? (En realidad creo que el problema pueden ser otras tablas que
apunten a esta). Prueba un EXPLAIN ANALYZE del update: deberia mostrar
el tiempo usado en revisar esto. Por ej

alvherre=# explain analyze update foo set a = a + 10000000 where a > 200000;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
Index Scan using foo_a_key on foo (cost=0.00..5182.19 rows=49640 width=10) (actual time=238.221..2111.175 rows=248000 loops=1)
Index Cond: (a > 200000)
Trigger for constraint bar_a_fkey: time=85402.641 calls=248000
Total runtime: 97699.408 ms
(4 filas)

Ojo, hazlo en una transaccion y luego haz ROLLBACK, porque las acciones
del UPDATE son ejecutadas.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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?

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

saludos

2008/1/29, Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Ernesto Quiñones escribió:
> > Hola amigos
> > tengo una tabla de 250k registros, tengo que correrle un update de mas
> > o menos 180k registros, el problema es que esta tomando bastante
> > tiempo, a veces mas de 15minutos, la tabla pasa por vacumm
> > continuamente y no tiene deletes solo procedimientos de insert diarios
> > que suben algo de 1000 registros nuevos diariamente
>
> Hmm, 250k registros deberian actualizarse mucho mas rapido que eso.
>
> alvherre=# create table foo (a int);
> CREATE TABLE
> alvherre=# insert into foo select * from generate_series(1, 250000);
> INSERT 0 250000
> alvherre=# \timing
> Mostrar tiempos está activado.
> alvherre=# update foo set a = a + 1;
> UPDATE 250000
> Duración: 3518,455 ms
> alvherre=# vacuum foo;
> VACUUM
> Duración: 281,051 ms
>
>
> Quizas tu problema tiene que ver con chequeos de FKs. ¿Tiene alguna FK
> la tabla? (En realidad creo que el problema pueden ser otras tablas que
> apunten a esta). Prueba un EXPLAIN ANALYZE del update: deberia mostrar
> el tiempo usado en revisar esto. Por ej
>
> alvherre=# explain analyze update foo set a = a + 10000000 where a > 200000;
> QUERY PLAN
> ---------------------------------------------------------------------------------------------------------------------------------
> Index Scan using foo_a_key on foo (cost=0.00..5182.19 rows=49640 width=10) (actual time=238.221..2111.175 rows=248000 loops=1)
> Index Cond: (a > 200000)
> Trigger for constraint bar_a_fkey: time=85402.641 calls=248000
> Total runtime: 97699.408 ms
> (4 filas)
>
>
> Ojo, hazlo en una transaccion y luego haz ROLLBACK, porque las acciones
> del UPDATE son ejecutadas.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>

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

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

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

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.

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

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.

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.

Ernesto Quiñones wrote:
> Hola amigos
> tengo una tabla de 250k registros, tengo que correrle un update de mas
> o menos 180k registros, el problema es que esta tomando bastante
> tiempo, a veces mas de 15minutos, la tabla pasa por vacumm
> continuamente y no tiene deletes solo procedimientos de insert diarios
> que suben algo de 1000 registros nuevos diariamente
>
> es posible mejorar ese tiempo en el update? a lo mejor bloqueando la
> tabla o algo así?, esta tabla solo es consultada por un par de
> personas que facilmente pueden esperar el fin del proceso de update de
> la tabla
>
> alguna idea que me pueda ayudar?
>
> saludos
>
>
Hola que hacen los updates?, porque es necesario correrlos a diario?
Que version de postgres usas?

Saludos Fernando

Ernesto Quiñones escribió:
> 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

Hmm, 33 segundos igual es mas de lo que yo esperaria, creo ...

> 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

Quizas otra cosa que podrias hacer es buscar un FILLFACTOR adecuado para
los indices y para la tabla. En la tabla, esto permitiria usar el mismo
bloque en la actualizacion de cada tupla; y en los indices, permitiria
tener que hacer menos "splits" (divisiones de pagina).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

marcelo Cortez escribió:
> Alvaro , gente
>
> >
> > Ojo, hazlo en una transaccion y luego haz ROLLBACK,
> > porque las acciones
> > del UPDATE son ejecutadas.
>
> El explain analyze de update se ejecuta???
> huu menos mal que no lo intente!! jejeje
> no lo sabia!.
> explain analyze delete .... tambien se ejecuta??

Por supuesto ...

> pd: esta creciendo la lista no? :)

�Sera el calor?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

2008/1/30, Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
>
> Ernesto Quiñones escribió:
> > 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
>
> Hmm, 33 segundos igual es mas de lo que yo esperaria, creo ...

¿Te parece? ¿En qué máquina lo estás corriendo?
El analizador dice que está modificando casi 200K de registros.
Dependiendo del HW, no es mucho.
Silvio

Es una AMD64 con 1gb de ram y disco sata
no es mucho fierro pero me sirve para las pruebas, la real esta
corriendo en un dual core con 2gb de ram y 2 discos sata
saludos

El 30/01/08, Silvio Quadri <silvioq(at)gmail(dot)com> escribió:
>
>
> 2008/1/30, Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> > Ernesto Quiñones escribió:
> > > 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
> >
> > Hmm, 33 segundos igual es mas de lo que yo esperaria, creo ...
>
>
> ¿Te parece? ¿En qué máquina lo estás corriendo?
> El analizador dice que está modificando casi 200K de registros.
> Dependiendo del HW, no es mucho.
> Silvio
>
>
>

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

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

Silvio Quadri escribió:
> 2008/1/30, Alvaro Herrera <alvherre(at)commandprompt(dot)com>:

> > Hmm, 33 segundos igual es mas de lo que yo esperaria, creo ...
>
> ¿Te parece? ¿En qué máquina lo estás corriendo?
> El analizador dice que está modificando casi 200K de registros.
> Dependiendo del HW, no es mucho.

alvherre=# create table r200k (a int, b text);
CREATE TABLE
alvherre=# insert into r200k select a, num2pal(a % 10000) from generate_series(1, 200000) a;
INSERT 0 200000
Time: 9347,207 ms
alvherre=# update r200k set b = num2pal((a + 1) % 10000);
UPDATE 200000
Time: 9159,006 ms

Doscientos mil registros actualizados en nueve segundos. El disco es un
RAID 1 (espejo) de dos discos SATA (/home).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

con alguna configuración especial? yo probe mi update con la
configuración pro defecto que trae ubuntu
saludos

2008/1/31, Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Silvio Quadri escribió:
> > 2008/1/30, Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
>
> > > Hmm, 33 segundos igual es mas de lo que yo esperaria, creo ...
> >
> > ¿Te parece? ¿En qué máquina lo estás corriendo?
> > El analizador dice que está modificando casi 200K de registros.
> > Dependiendo del HW, no es mucho.
>
> alvherre=# create table r200k (a int, b text);
> CREATE TABLE
> alvherre=# insert into r200k select a, num2pal(a % 10000) from generate_series(1, 200000) a;
> INSERT 0 200000
> Time: 9347,207 ms
> alvherre=# update r200k set b = num2pal((a + 1) % 10000);
> UPDATE 200000
> Time: 9159,006 ms
>
> Doscientos mil registros actualizados en nueve segundos. El disco es un
> RAID 1 (espejo) de dos discos SATA (/home).
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>

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

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

Ernesto Quiñones escribió:
> con alguna configuración especial? yo probe mi update con la
> configuración pro defecto que trae ubuntu

8.2.6, configuracion por defecto (shared_buffers=24MB). El servidor no
tiene ningun otro uso concurrente eso si.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.