Re: A 154 GB table swelled to 527 GB on the Slony slave. How to compact it?

From: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
To: pgsql-general(at)postgresql(dot)org, atsaloli(dot)tech(at)gmail(dot)com
Subject: Re: A 154 GB table swelled to 527 GB on the Slony slave. How to compact it?
Date: 2012-03-16 21:03:45
Message-ID: 4F63AAB1.8090605@pinpointresearch.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Davis 2012-03-16 21:13:48 Re: Temporal foreign keys
Previous Message Scott Marlowe 2012-03-16 20:35:21 Re: A 154 GB table swelled to 527 GB on the Slony slave. How to compact it?