From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kurt Overberg <kurt(at)hotdogrecords(dot)com> |
Cc: | Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Maintenance question / DB size anomaly... |
Date: | 2007-06-20 15:22:37 |
Message-ID: | 18180.1182352957@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Kurt Overberg <kurt(at)hotdogrecords(dot)com> writes:
> Okay, so the sl_log_1 TABLE looks okay. Its the indexes that seem to
> be messed up, specifically sl_log_1_idx1 seems to think that there's
>>> 300,000 rows in the table its associated with. I just want to fix
> the index, really.
I'm not sure how you arrive at that conclusion. The VACUUM VERBOSE
output you provided here:
http://archives.postgresql.org/pgsql-performance/2007-06/msg00370.php
shows clearly that there are lots of rows in the table as well as
the indexes. A REINDEX would certainly cut the size of the indexes
but it isn't going to do anything about the extraneous rows.
When last heard from, you were working on getting pg_filedump output for
some of the bogus rows --- what was the result?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | RESTOUX | 2007-06-20 15:27:52 | Re: [PG 8.1.0 / AIX 5.3] Vacuum processes freezing |
Previous Message | Greg Smith | 2007-06-20 15:21:01 | Re: Volunteer to build a configuration tool |