strategies for dealing with frequently updated tables

Hi all,

I have a relation where a tuple typically undergoes a lifecycle
something like:
1) Created
2) Updated maybe thousands of times (no updates to indexed columns though)
3) Rarely or never modified again

The following query takes about 100 minutes (3 seconds per tuple):
SELECT count(id) from T

(2) is causing a lot of auto vacuum/analyze activity (which is OK). HOT
seems to get used for about 90% of the updates, but there are enough
updates that don't use it to cause issues. I'm using pg version 9.0.3
on a 32-bit windows xp machine with 3GB of RAM. The .conf file is using
default settings.

Table Info:
n_live_tup 1799
n_dead_tup 191
pg_relation_size 2343mb
indexsize 10mb
toastsize 552kb
toastindexsize 16kb

This reports under 10kb for most tuples:
psql -A -c "select * from T where id=123" | wc -c

auto-vacuum and auto-analyze both ran yesterday with default settings.
There are only one or two new tuples since yesterday. The database is
fairly old (was probably created using pg_restore about when 9.0.3 came
out).

Here is the output from VACUUM VERBOSE:
INFO: vacuuming "public.T"
INFO: scanned index "idx1" to remove 249 row versions
DETAIL: CPU 0.00s/0.00u sec elapsed 2.00 sec.
INFO: scanned index "idx2" to remove 249 row versions
DETAIL: CPU 0.00s/0.00u sec elapsed 2.12 sec.
INFO: scanned index "idx3" to remove 249 row versions
DETAIL: CPU 0.00s/0.00u sec elapsed 2.90 sec.
INFO: scanned index "idx4" to remove 249 row versions
DETAIL: CPU 0.00s/0.00u sec elapsed 2.32 sec.
INFO: scanned index "idx5" to remove 249 row versions
DETAIL: CPU 0.00s/0.00u sec elapsed 2.42 sec.
INFO: "T": removed 249 row versions in 249 pages
DETAIL: CPU 0.00s/0.00u sec elapsed 0.06 sec.
INFO: index "idx1" now contains 1976 row versions in 252 pages
DETAIL: 249 index row versions were removed.
210 index pages have been deleted, 210 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO: index "idx2" now contains 1976 row versions in 258 pages
DETAIL: 249 index row versions were removed.
209 index pages have been deleted, 209 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.07 sec.
INFO: index "idx3" now contains 1976 row versions in 259 pages
DETAIL: 249 index row versions were removed.
217 index pages have been deleted, 217 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.06 sec.
INFO: index "idx4" now contains 1976 row versions in 250 pages
DETAIL: 249 index row versions were removed.
206 index pages have been deleted, 206 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.07 sec.
INFO: index "idx5" now contains 1976 row versions in 267 pages
DETAIL: 249 index row versions were removed.
217 index pages have been deleted, 217 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.06 sec.
INFO: "T": found 0 removable, 1444 nonremovable row versions in 1522
out of 299964 pages
DETAIL: 30 dead row versions cannot be removed yet.
There were 10035 unused item pointers.
0 pages are entirely empty.
CPU 0.01s/0.00u sec elapsed 17.24 sec.
INFO: vacuuming "pg_toast.pg_toast_17132"
INFO: index "pg_toast_17132_index" now contains 279 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO: "pg_toast_17132": found 0 removable, 279 nonremovable row
versions in 69 out of 69 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.56 sec.
VACUUM

I imagine CLUSTERing the table would make things happier, but I'm hoping
for a permanent solution that avoids periodic downtime.

One thought was to partition so rows that are still changing live in a
separate table from the more stable rows. I imagine the cardinality of
(2) rarely exceeds 10. Can I still get into performance trouble with a
table that small after enough updates? Anyone have other ideas?

- Dave