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

From Steve Crawford
Subject Re: A 154 GB table swelled to 527 GB on the Slony slave. How to compact it?
Date
Msg-id 4F63AAB1.8090605@pinpointresearch.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?
List pgsql-general
I'm coming into this conversation *way* late so forgive me if this has
been hashed out already

On 03/16/2012 12:20 PM, Aleksey Tsalolikhin wrote:
> CLUSTER requires free space at least equal to the sum of the tablesize
> and the index sizes.
>

Although it is not documented in an absolutely clear way, I do not
believe this is true in part due to the different cluster options and
the lack of specificity on whether tablesize refers to the on-disk size
of the new or the old table.

I *think* you can get away with only sufficient free space to store the
*new* table and indexes which, on a heavily bloated table, may be
significantly less than the space required for a full copy of the
bloated table/indexes.

Depending on your schema and which tables are using space, you might be
able to start clustering the smaller tables and progressively free
additional space that can be used when clustering the larger tables.

> Too bad there is no way to compact the rows/pages within the table
> without using an
> temporary table.  That would be the silver bullet for my particular
> predicament.
Isn't that "VACUUM FULL"? Much slower than CLUSTER and can cause index
bloat (solvable by subsequent reindexing) but does not create a
duplicate of the table.

Cheers,
Steve


pgsql-general by date:

Previous
From: Aleksey Tsalolikhin
Date:
Subject: Re: A 154 GB table swelled to 527 GB on the Slony slave. How to compact it?
Next
From: Jeff Davis
Date:
Subject: Re: Temporal foreign keys