Hi Tom,

Thanks for info. I stoped the update and removed the process that's doing
the update and did vacuum analyze. This time the result says
the index row has been removed :

vacuum verbose analyze dsperf_rda_or_key;
INFO: vacuuming "scncraft.dsperf_rda_or_key"
INFO: index "dsperf242_1105" now contains 300000 row versions in 12387 pages
DETAIL: 3097702 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 2.86s/25.49u sec elapsed 54.16 sec.
INFO: "dsperf_rda_or_key": removed 3097702 row versions in 53726 pages
DETAIL: CPU 6.29s/26.05u sec elapsed 78.23 sec.
INFO: "dsperf_rda_or_key": found 3097702 removable, 300000 nonremovable row versions in 58586 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 5 unused item pointers.
0 pages are entirely empty.
CPU 10.23s/53.79u sec elapsed 135.78 sec.
INFO: analyzing "scncraft.dsperf_rda_or_key"
INFO: "dsperf_rda_or_key": 58586 pages, 3000 rows sampled, 176830 estimated total rows

However, when I check the disk space usage, it has not changed.
Before and after the vacuum, it stayed the same :

/pg 822192 21% Sun Oct 19 09:34:25 CDT 2003
table /pg/data/base/17139/34048 Size=479936512 (relfilenode for table)
index /pg/data/base/17139/336727 Size=101474304 (relfilenode for index)

Any idea here ?

Another question, if we have a process that has different threads trying
to update PostgreSQL, is this going to post a problem if we do not have
the thread-safety option during configure ?



At 1:48 am -0400 2003/10/19, Tom Lane wrote:
Seum-Lim Gan <[EMAIL PROTECTED]> writes:
 INFO:  vacuuming "craft.dsperf_rda_or_key"
 INFO:  index "hello242_1105" now contains 1792276 row versions in 6237 pages
 DETAIL:  0 index pages have been deleted, 0 are currently reusable.
 CPU 0.61s/0.36u sec elapsed 17.92 sec.
 INFO:  "hello_rda_or_key": found 0 removable, 1791736 nonremovable
 row versions in 30892 pages
 DETAIL:  1492218 dead row versions cannot be removed yet.

You still haven't got an index-bloat problem. I am, however, starting to wonder why you have so many dead-but-unremovable rows. I think you must have some client process that's been holding an open transaction for a long time.

regards, tom lane

| Seum-Lim GAN                 email : [EMAIL PROTECTED]  |
| Lucent Technologies                                    |
| 2000 N. Naperville Road, 6B-403F  tel : (630)-713-6665 |
| Naperville, IL 60566, USA.        fax : (630)-713-7272 |
|       web : http://inuweb.ih.lucent.com/~slgan         |

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to