From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Ernesto Quiñones <ernestoq(at)gmail(dot)com> |
Cc: | ListaPostGres <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: es posible acelerar un update? |
Date: | 2008-01-30 14:28:04 |
Message-ID: | 20080130142804.GB4536@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-01-30 14:31:06 | Re: El API pgsql en C |
Previous Message | Carlos Mendez | 2008-01-30 13:55:56 | como anidar funciones plpgsql |