From: Bruno Wolff III <bruno@wolff.to>
To: Assaf Yaari <assafy@mobixell.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Performance degradation after successive UPDATE's
Date: Tue, 6 Dec 2005 14:44:33 -0600
Message-ID: <20051206204433.GA22168@wolff.to> (raw)
In-Reply-To: <A3F53DEA945DA44386457F03BA78465F9D12AC@mobiexc.mobixell.com>
References: <A3F53DEA945DA44386457F03BA78465F9D12AC@mobiexc.mobixell.com>
On Tue, Dec 06, 2005 at 11:08:07 +0200,
Assaf Yaari <assafy@mobixell.com> wrote:
> Thanks Bruno,
>
> Issuing VACUUM FULL seems not to have influence on the time.
That was just to get the table size back down to something reasonable.
> I've added to my script VACUUM ANALYZE every 100 UPDATE's and run the
> test again (on different record) and the time still increase.
Vacuuming every 100 updates should put an upperbound on how slow things
get. I doubt you need to analyze every 100 updates, but that doesn't
cost much more on top of a vacuum. However, if there is another transaction
open while you are doing the updates, that would prevent clearing out
the deleted rows, since they are potentially visible to it. This is something
you want to rule out.
> Any other ideas?
Do you have any triggers on this table? Are you updating any other tables
at the same time? In particular ones that are referred to by the problem table.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: bruno@wolff.to, assafy@mobixell.com
Subject: Re: Performance degradation after successive UPDATE's
In-Reply-To: <20051206204433.GA22168@wolff.to>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox