Skip site navigation (1) Skip section navigation (2)

Re: remove flatfiles.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: remove flatfiles.c
Date: 2009-09-01 23:42:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Wed, Sep 2, 2009 at 12:01 AM, Alvaro
> Herrera<alvherre(at)commandprompt(dot)com> wrote:
>>> The use cases where VACUUM FULL wins currently are where storing two
>>> copies of the table and its indexes concurrently just isn't practical.
>> Yeah, but then do you really need to use VACUUM FULL? If that's really
>> a problem then there ain't that many dead tuples around.

> 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.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2009-09-01 23:51:06
Subject: Re: Linux LSB init script
Previous:From: Greg StarkDate: 2009-09-01 23:34:07
Subject: Re: remove flatfiles.c

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group