Re: [PERFORM] Performance degradation after successive UPDATE's

2005-12-08 Thread Assaf Yaari
rows) Time: 0.666 ms > -Original Message- > From: Bruno Wolff III [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 07, 2005 10:05 PM > To: Assaf Yaari > Cc: Jan Wieck; pgsql-performance@postgresql.org > Subject: Re: [PERFORM] Performance degradation after >

Re: [PERFORM] Performance degradation after successive UPDATE's

2005-12-07 Thread Bruno Wolff III
Have you given us explain analyse samples yet? > > Thanks, > Assaf. > > > -Original Message- > > From: Jan Wieck [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, December 06, 2005 2:35 PM > > To: Assaf Yaari > > Cc: Bruno Wolff III; pgsql-performance@

Re: [PERFORM] Performance degradation after successive UPDATE's

2005-12-07 Thread Assaf Yaari
ctions are open. Thanks, Assaf. > -Original Message- > From: Jan Wieck [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 06, 2005 2:35 PM > To: Assaf Yaari > Cc: Bruno Wolff III; pgsql-performance@postgresql.org > Subject: Re: [PERFORM] Performance degradation after >

Re: [PERFORM] Performance degradation after successive UPDATE's

2005-12-06 Thread Bruno Wolff III
On Tue, Dec 06, 2005 at 11:08:07 +0200, Assaf Yaari <[EMAIL PROTECTED]> 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

Re: [PERFORM] Performance degradation after successive UPDATE's

2005-12-06 Thread Jan Wieck
On 12/6/2005 4:08 AM, Assaf Yaari wrote: Thanks Bruno, Issuing VACUUM FULL seems not to have influence on the time. 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. I think he meant - run VACUUM FULL once,

Re: [PERFORM] Performance degradation after successive UPDATE's

2005-12-06 Thread Pandurangan R S
Hi, You might try these steps 1. Do a vacuum full analyze 2. Reindex the index on id column 3. Cluster the table based on this index On 12/5/05, Assaf Yaari <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm using PostgreSQL 8.0.3 on Linux RedHat WS 3.0. > > My application updates counters in DB. I left

Re: [PERFORM] Performance degradation after successive UPDATE's

2005-12-06 Thread Assaf Yaari
Thanks Bruno, Issuing VACUUM FULL seems not to have influence on the time. 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. Any other ideas? Thanks, Assaf. > -Original Message- > From: Bruno Wolff III [m

Re: [PERFORM] Performance degradation after successive UPDATE's

2005-12-05 Thread Bruno Wolff III
On Mon, Dec 05, 2005 at 19:05:01 +0200, Assaf Yaari <[EMAIL PROTECTED]> wrote: > Hi, > > I'm using PostgreSQL 8.0.3 on Linux RedHat WS 3.0. > > My application updates counters in DB. I left a test over the night that > increased counter of specific record. After night running (several > hundr

[PERFORM] Performance degradation after successive UPDATE's

2005-12-05 Thread Assaf Yaari
Hi,   I'm using PostgreSQL 8.0.3 on Linux RedHat WS 3.0.   My application updates counters in DB. I left a test over the night that increased counter of specific record. After night running (several hundreds of thousands updates), I found out that the time spent on UPDATE increased to be mor