Re: remove flatfiles.c

From: Rod Taylor <rod(dot)taylor(at)gmail(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: remove flatfiles.c
Date: 2009-09-02 01:34:58
Message-ID: 751261b20909011834g5e08e7c0hc8e789f15b3fecb8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 1, 2009 at 19:34, Greg Stark <gsstark(at)mit(dot)edu> wrote:

> On Wed, Sep 2, 2009 at 12:01 AM, Alvaro
> Herrera<alvherre(at)commandprompt(dot)com> wrote:
> >> The use cases where VACUUM FULL wins currently are where storing two
> >> copies of the table and its indexes concurrently just isn't practical.
> >
> > Yeah, but then do you really need to use VACUUM FULL? If that's really
> > a problem then there ain't that many dead tuples around.
>
> That's what I want to believe. But picture if you have, say a
> 1-terabyte table which is 50% dead tuples and you don't have a spare
> 1-terabytes to rewrite the whole table.
>

It would be interesting if there was something between VACUUM FULL and
CLUSTER which could, say, work on a single 1GB segment at a time in a manner
similar to cluster.

You would still end up with index bloat like vacuum full, though perhaps not
as bad, but shuffling around the tuples should be faster.

The idea here is that the files can be truncated individually. Two 500MB
files is pretty much the same as a single 1GB file on disk.

Of course, I'm hand waving and don't have the technical expertise to figure
out if it can be done easily within PostgreSQL.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-09-02 01:43:37 Re: Linux LSB init script
Previous Message Alvaro Herrera 2009-09-02 01:29:33 Re: remove flatfiles.c