Re: remove flatfiles.c

From: Andrew McNamara <andrewm(at)object-craft(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: remove flatfiles.c
Date: 2009-09-16 06:33:40
Message-ID: 20090916063341.0735C5AC0D6@longblack.object-craft.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> That's what I want to believe. But picture if you have, say a
>> 1-terabyte table which is 50% dead tuples and you don't have a spare
>> 1-terabytes to rewrite the whole table.
>
>But trying to VACUUM FULL that table is going to be horridly painful
>too, and you'll still have bloated indexes afterwards. You might as
>well just live with the 50% waste, especially since if you did a
>full-table update once you'll probably do it again sometime.
>
>I'm having a hard time believing that VACUUM FULL really has any
>interesting use-case anymore.

This was almost exactly the scenario I faced recently. A production
database unexpectedly filled up its partition. On investigation, we found
a developer had added a component to the application that updated every
row in one table each day, exhausting the free space map. Over time,
most of the tables in the system had grown to contain 50-70% dead tuples.

The owner of the system was understandably reluctant to dump and restore
the system, and there wasn't enough space left on the system to rewrite
any of the large tables. In the end, I dropped a table (the one owned
by the offending developer... 8-), and this gave me just enough space
to VACUUM FULL one table at a time.

--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Abhijit Menon-Sen 2009-09-16 06:45:16 Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW]
Previous Message Abhijit Menon-Sen 2009-09-16 06:27:34 Re: Logging configuration changes [REVIEW]