Re: remove flatfiles.c

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

In response to

Responses

Browse pgsql-hackers by date

  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