Re: Vacuum only with 20% old tuples

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Vacuum only with 20% old tuples
Date: 2000-07-12 02:49:11
Message-ID: 200007120249.WAA03417@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> We can't "drop and recreate" without a solution to the relation
> versioning issue (unless you are prepared to accept a nonfunctional
> database after a failure partway through index rebuild on a system
> table). I think we should do this, but it's not all that simple...
>
> I do not see what your 20% idea has to do with this, though, nor
> why it's a good idea. If I've told the thing to vacuum I think
> it should vacuum. 20% of a big table could be a lot of megabytes,
> and I don't want some arbitrary decision in the code about whether
> I can reclaim that space or not.

Well, I think we should do a sequential scan before starting vacuum to
find the number of expired rows.

Now that we are removing indexes, doing that to remove a few tuples is a
major waste. The user can not really know if the table is worth
vacuuming in normal use. They are just going to use the default. Now,
I think a FORCE option would be good, or the ability to change the 20%
default.

Remember, commercial db's don't even return unused space if you remove
all the rows in a table. At least Informix doesn't and I am sure there
are others. I like vacuum, but let's not make it do major hurtles for
small gain.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-07-12 03:05:10 Re: Re: postgres TODO
Previous Message Philip Warner 2000-07-12 02:15:09 Re: Insert..returning (was Re: Re: postgres TODO)