| From: | Daniel Farina <daniel(at)heroku(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #8058: CLUSTER and VACUUM FULL fail to free space |
| Date: | 2013-04-12 18:05:39 |
| Message-ID: | CAAZKuFasjFLz1tg00TLe8-O54n3D6b+4b-e+0r3C6m2beT8cbg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Apr 12, 2013 at 7:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> daniel(at)heroku(dot)com writes:
>> We have a somewhat high-churn table acting as a queue, and over time it's
>> grown to be something like a gigabyte. I surmised it might be vanilla
>> bloat, but the truth seems somewhat more exotic because both VACUUM FULL and
>> CLUSTER generated absolutely no new free space.
>
>> In the end, ALTER TABLE and CREATE TABLE ... (LIKE) ran nearly instantly and
>> got the table size down to a few hundred K from 900M.
>
> My money is on there being old idle transactions somewhere that kept
> recently-dead rows from being reclaimable. If memory serves, VACUUM
> FULL and CLUSTER will faithfully retain such rows, but of course a
> manual data transfer like that wouldn't.
>
>> We have retained the old bloated table so we can poke at it.
>
> I think contrib/pgstattuple could tell you about dead tuples.
Yeah, you and Andres are on the mark, although the cause is
potentially a bit less visible: hot standby feedback. Also, my
misunderstanding of VACUUM FULL/CLUSTER's interaction with snapshots,
which I thought more similar to DDL for no reason in particular.
Sorry about the noise.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | fburgess | 2013-04-12 18:31:33 | Partition performance causing ddl commands to slow down significantly |
| Previous Message | Daniel Farina | 2013-04-12 17:56:39 | Re: BUG #8058: CLUSTER and VACUUM FULL fail to free space |