From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: remove flatfiles.c |
Date: | 2009-09-02 18:01:02 |
Message-ID: | 4A9EB2DE.6090108@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2009-09-02 18:07:04 | Re: remove flatfiles.c |
Previous Message | Kevin Grittner | 2009-09-02 17:57:29 | Re: remove flatfiles.c |