Re: Vacuum improvement - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: Vacuum improvement
Date
Msg-id Pine.LNX.4.21.0210161725160.15094-100000@linuxworld.com.au
Whole thread Raw
In response to Re: Vacuum improvement  (Hannu Krosing <hannu@tm.ee>)
Responses Re: Vacuum improvement  (Greg Copeland <greg@CopelandConsulting.Net>)
List pgsql-hackers
On 16 Oct 2002, Hannu Krosing wrote:

> On Wed, 2002-10-16 at 05:22, Gavin Sherry wrote:
> > Hi all,
> > 
> > I'm thinking that there is an improvement to vacuum which could be made
> > for 7.4. VACUUM FULLing large, heavily updated tables is a pain. There's
> > very little an application can do to minimise dead-tuples, particularly if
> > the table is randomly updated. Wouldn't it be beneficial if VACUUM could
> > have a parameter which specified how much of the table is vacuumed. That
> > is, you could specify:
> > 
> > VACUUM FULL test 20 precent;
> 
> What about
> 
> VACUUM FULL test WORK 5 SLEEP 50;
> 
> meaning to VACUUM FULL the whole table, but to work in small chunks and
> relaese all locks and let others access the tables between these ?

Great idea. I think this could work as a complement to the idea I had. To
answer Tom's question, how would we know what we've vacuumed, we could
store the range of tids we've vacuumed in pg_class. Or, we could store the
block offset of where we left off vacuuming before and using stats, run
for another X% of the heap. Is this possible?

Gavin



pgsql-hackers by date:

Previous
From: "Shridhar Daithankar"
Date:
Subject: Re: [GENERAL] Postgres-based system to run .org registry?
Next
From: Daniel Kalchev
Date:
Subject: Re: DROP USER weirdness in 7.2.1