Re: Vacuum improvement

From: David Walker <pgsql(at)grax(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vacuum improvement
Date: 2002-10-16 16:33:35
Message-ID: 200210161133.35771.pgsql@grax.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vacuum full locks the whole table currently. I was thinking if you used a
similar to a hard drive defragment that only 2 rows would need to be locked
at a time. When you're done vacuum/defragmenting you shorten the file to
discard the dead tuples that are located after your useful data. There might
be a need to lock the table for a little while at the end but it seems like
you could reduce that time greatly.

I had one table that is heavily updated and it grew to 760 MB even with
regular vacuuming. A vacuum full reduced it to 1.1 MB. I am running 7.2.0
(all my vacuuming is done by superuser).

On Wednesday 16 October 2002 09:30 am, (Via wrote:
> On Wed, 2002-10-16 at 02:29, Gavin Sherry wrote:
> > 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?
>
> Why couldn't you start your % from the first rotten/dead tuple? Just
> reading through trying to find the first tuple to start counting from
> wouldn't hold locks would it? That keeps you from having to track stats
> and ensures that X% of the tuples will be vacuumed.
>
> Greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Copeland 2002-10-16 16:52:43 Re: Vacuum improvement
Previous Message Hannu Krosing 2002-10-16 15:47:00 Re: index theory