| 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: | Whole Thread | Raw Message | 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 |