| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Chris Browne <cbbrowne(at)acm(dot)org> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Maintenance question / DB size anomaly... |
| Date: | 2007-06-19 16:04:19 |
| Message-ID: | 160.1182269059@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Chris Browne <cbbrowne(at)acm(dot)org> writes:
> kurt(at)hotdogrecords(dot)com (Kurt Overberg) writes:
>> In my investigation of this anomaly, I noticed that the data/ dir on
>> db1 (the master) is around 60 Gigs. The data directory on the slaves
>> is around 25Gb. After about 3 months of head scratching, someone on
>> the irc channel suggested that it may be due to index bloat.
> I'd be inclined to head to the filesystem level, and try to see what
> tables are bloated *there*.
At least as a first cut, it should be sufficient to look at
pg_class.relpages, which'd be far easier to correlate with table names
;-). The relpages entry should be accurate as of the most recent VACUUM
on each table, which ought to be close enough unless I missed something
about the problem situation.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2007-06-19 16:12:05 | Re: Performance query about large tables, lots of concurrent access |
| Previous Message | Josh | 2007-06-19 16:03:46 | Re: [PERFORM] Postgres VS Oracle |