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: | Raw Message | Whole Thread | 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 |