From: | Greg Copeland <greg(at)CopelandConsulting(dot)Net> |
---|---|
To: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
Cc: | Hannu Krosing <hannu(at)tm(dot)ee>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Vacuum improvement |
Date: | 2002-10-16 14:30:01 |
Message-ID: | 1034778601.397.1401.camel@mouse.copelandconsulting.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2002-10-16 14:37:02 | Re: Postgresql and multithreading |
Previous Message | Greg Copeland | 2002-10-16 14:21:54 | Re: Postgresql and multithreading |