Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] UPDATE performance degradation (6.5.1)

From: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] UPDATE performance degradation (6.5.1)
Date: 1999-07-27 15:46:38
Message-ID: Pine.GSO.3.96.SK.990727193953.29708L-100000@ra (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, 27 Jul 1999, Tom Lane wrote:

> Date: Tue, 27 Jul 1999 10:57:36 -0400
> From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> To: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
> Cc: pgsql-hackers(at)postgreSQL(dot)org
> Subject: Re: [HACKERS] UPDATE performance degradation (6.5.1) 
> Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
> > and after vacuum analyze:
> > -rw-------   1 postgres users        8192 Jul 27 18:54 hits
> > -rw-------   1 postgres users     1703936 Jul 27 18:54 hits_pkey
> > Why hits_pkey is so big ? I have only 7 rows in the table.
> Looks like vacuum reclaims the extra space in the table itself,
> but does not do so with indexes.  Ugh.

And do we consider this as a bug ? How do correcting of vacuum
could change poor performance ?

I just rebuild my table without using indices and performace increased
a lot. But this is undesirable because it will slowdown my application.
I'll try dbm files for logging instead of postgres. What's the shame :-)


> I've thought for some time that vacuum ought to drop and rebuild
> indexes instead of trying to update them.  This might be another
> reason for doing that...
> 			regards, tom lane

Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su,
phone: +007(095)939-16-83, +007(095)939-23-83

In response to

pgsql-hackers by date

Next:From: Thomas LockhartDate: 1999-07-27 16:12:05
Subject: Re: [ANNOUNCE] i386 RPMs available for v6.5.1
Previous:From: Thomas LockhartDate: 1999-07-27 15:43:35
Subject: Re: [PORTS] RedHat6.0 & Alpha

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group