Re: remove flatfiles.c - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: remove flatfiles.c
Date
Msg-id 4A9EB2DE.6090108@agliodbs.com
Whole thread Raw
In response to Re: remove flatfiles.c  (Greg Stark <gsstark@mit.edu>)
Responses Re: remove flatfiles.c
Re: remove flatfiles.c
List pgsql-hackers
Greg,

> I don't think we want to cluster on the primary key. I think we just
> want to rewrite the table keeping the same physical ordering.

Agreed.

> Well I've certainly seen people whose disks are more than 50% full.
> They tend to be the same people who want to compact their tables. I
> can't say whether any of them had a single table with associated
> indexes that were taking up more than 50% but it's not uncommon to
> have a single table that dominates your database.

Those people would also need for the tables involved to be fairly small,
or to be able to afford a lot of downtime.  VACUUM FULL on a 100GB table
with current commodity servers can take upwards of 8 hours.  I really
think the cases of people who have more available downtime than disk
space is is vanishingly small group.

However, I'll do a survey.  Why not?

> We could deal with the admin scripts by making VACUUM FULL do the new
> behaviour. But I actually don't really like that. I wold prefer to
> break VACUUM FULL since anyone doing it routinely is probably
> mistaken. We could name the command something which is more
> descriptive like VACUUM REWRITE or VACUUM REBUILD or something like
> that.

Agreed.  I like VACUUM REWRITE, as it makes it fairly clear what's going on.

-- 
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: remove flatfiles.c
Next
From: "Joshua D. Drake"
Date:
Subject: Re: remove flatfiles.c