| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Seum-Lim Gan <slgan(at)lucent(dot)com> |
| Cc: | josh(at)agliodbs(dot)com, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: index file bloating still in 7.4 ? |
| Date: | 2003-10-20 21:42:52 |
| Message-ID: | 15968.1066686172@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Seum-Lim Gan <slgan(at)lucent(dot)com> writes:
> [ successive outputs from VACUUM ANALYZE ]
FWIW, I don't think your problem is really index bloat at all, it's
more like too-many-dead-rows bloat. Note that the number of "dead row
versions" is climbing steadily from run to run:
> DETAIL: 101802 dead row versions cannot be removed yet.
> DETAIL: 110900 dead row versions cannot be removed yet.
> DETAIL: 753064 dead row versions cannot be removed yet.
> DETAIL: 765328 dead row versions cannot be removed yet.
It's hardly the index's fault that it's growing, when it has to keep
track of an ever-increasing number of rows.
The real question is what you're doing that requires the system to keep
hold of these dead rows instead of recycling them. I suspect you have
a client process somewhere that is holding an open transaction for a
long time ... probably not doing anything, just sitting there with an
unclosed BEGIN ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2003-10-21 00:55:12 | SRFs ... no performance penalty? |
| Previous Message | Tom Lane | 2003-10-20 21:25:13 | Re: index file bloating still in 7.4 ? |