Re: [HACKERS] UPDATE performance degradation (6.5.1) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] UPDATE performance degradation (6.5.1)
Date
Msg-id 7070.933086380@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] UPDATE performance degradation (6.5.1)  (Oleg Bartunov <oleg@sai.msu.su>)
Responses Re: [HACKERS] UPDATE performance degradation (6.5.1)  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
Oleg Bartunov <oleg@sai.msu.su> writes:
> Probably I found the problem. After running my test, whiich  became
> very slow I looked at /usr/local/pgsql/data/base/discovery

> -rw-------   1 postgres users     5070848 Jul 27 16:14 hits
> -rw-------   1 postgres users     1409024 Jul 27 16:14 hits_pkey

> This is for table with one row  after a lot of updates.
> Too much. vacuum analyze this table was a good  medicine !

If the table contains only one row, why are you bothering with an
index on it?

> Is this a design problem ? 

Only that space in tables and indexes can't be re-used until vacuum.
I'm not sure if there's any good way around that or not...
        regards, tom lane


pgsql-hackers by date:

Previous
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: fmgr interface [was: plperl inital pass]
Next
From: Thomas Lockhart
Date:
Subject: i386 RPMs available for v6.5.1