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

From Joshua D. Drake
Subject Re: remove flatfiles.c
Date
Msg-id 1251913619.8406.37.camel@jd-desktop.unknown.charter.com
Whole thread Raw
In response to Re: remove flatfiles.c  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Wed, 2009-09-02 at 10:41 -0700, Josh Berkus wrote:
> All,
>
>
> > I'm having a hard time believing that VACUUM FULL really has any
> > interesting use-case anymore.
>
> Basically, for:
> a) people who don't understand CLUSTER (easily fixed, simply create a
> VACUUM FULL command which just does CLUSTER on the primary key)
>
> b) people who are completely out of space on disk and are trying to
> shrink the database to free up space.
>
> For (b), I think it's OK to just tell those people that they need to
> move the database files or find something else to delete.  Most of the
> time, they have to do that *anyway* in order for VACUUM FULL to work,
> since the transaction log is on the same disk.  We just need a little
> more documentation, is all.

Right.

>
> > The problem use cases we have today are only when you really do have
> > enough dead space to clean up that you want to compact the file -- but
> > not so much that it's worth rewriting the whole table using CLUSTER or
> > ALTER TABLE.
>
> I haven't seen this use-case in the field.  I'm not sure that it
> actually exists.  Anyone run across a case where this made sense?
>

No.

> Recently I actually had a client dump and reload their database rather
> than running VACUUM FULL; a reload took 4 hours but VACUUM FULL took
> more than 18.
>

Exactly.

> > Perhaps we should go one version with a enable_legacy_full_vacuum
> > which defaults to off. That would at least let us hear about use cases
> > where people are unhappy with a replacement.
>
> I think we do need to do this, just because people won't have changed
> their admin scripts.  But the goal should be to dump VACUUM FULL
> entirely by 8.6 if we *don't* get serious use-cases.
>

Agreed, but I think we shouldn't even put it in the postgresql.conf by
default. Just document that it exists. Settings for the sake of settings
(even ones that may have a corner case) seem to confuse users.

Joshua D. Drake


--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering

pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: remove flatfiles.c
Next
From: Greg Stark
Date:
Subject: Re: remove flatfiles.c