Re: A 154 GB table swelled to 527 GB on the Slony slave. How to compact it? - Mailing list pgsql-general

From Scott Marlowe
Subject Re: A 154 GB table swelled to 527 GB on the Slony slave. How to compact it?
Date
Msg-id CAOR=d=21Gmd+mHU3uapD-02kfTgFFXb8VoZzrG+pZigHCzDvuw@mail.gmail.com
Whole thread Raw
In response to Re: A 154 GB table swelled to 527 GB on the Slony slave. How to compact it?  (Aleksey Tsalolikhin <atsaloli.tech@gmail.com>)
Responses Re: A 154 GB table swelled to 527 GB on the Slony slave. How to compact it?
Re: A 154 GB table swelled to 527 GB on the Slony slave. How to compact it?
List pgsql-general
On Wed, Mar 14, 2012 at 9:06 PM, Aleksey Tsalolikhin
<atsaloli.tech@gmail.com> wrote:
>
> On Wed, Mar 14, 2012 at 7:38 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>>
>> The good news is that if the table is
>> bloated, it should be able to just write to the free space in the
>> table that's already there.
>
> Thank you, I got it.  The table is not bloated, as per
> check_postgres.pl --action=bloat

Are you sure you're checking the toast table that goes with whatever
parent table?

Easy way to tell. du -s /var/lib/data/base dir, then update a few
thousand rows, roll it back, and run du -s again.  Compare.  If the du
numbers stay the same then you're updating pre-allocated space and
should be ok.  If there's a delta, compute it per tuple updated,
multiply by tuples and that's how much you'll need.

If the du -s numbers don't change or only a little then feel free to
either run a single update while running

watch "df -h /var/lib/where/my/data/dir/lives"

and being ready to hit CTRL-C if you see if running your machine out of memory.

pgsql-general by date:

Previous
From: John R Pierce
Date:
Subject: yum repository packages 9.0 and 9.1 libpq conflict
Next
From: Scott Marlowe
Date:
Subject: Re: A 154 GB table swelled to 527 GB on the Slony slave. How to compact it?