From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>, shridhar_daithankar(at)persistent(dot)co(dot)in, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: 7.3.1 takes long time to vacuum table? |
Date: | 2003-02-20 04:21:40 |
Message-ID: | 20030220042140.GF10807@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Feb 19, 2003 at 10:37:45PM -0500, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > You could do the jump-back-in-blocks only if more than 30% of the table is
> > empty and table is over 1GB. For the example here, a simple defragging
> > algorithm would suffice; start at beginning and pack each tuple into the
> > beginning of the file. It will move *every* tuple but it's more cache
> > friendly. It's pretty extreme though.
>
> And your evidence that it will actually be faster is ... ?
Will, in this guy's example, the first stage of the vacuum (scan_heap)
finished in a few hours but the second stage is still going after 50 hours
and estimating a bit over half done. The major difference between the two is
that the latter goes backwards through the table and the other forwards.
Sure, it's anecdotal and a bit hand wavey but I think there's something to
it. Come to think of it, if that strace had used -tt it would have been
more interesting.
Anyway, the test would be to implement it and them time it. The vacuum code
looks scary though. I'm not sure if I want to mess with it...
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Support bacteria! They're the only culture some people have.
From | Date | Subject | |
---|---|---|---|
Next Message | Opis Boi | 2003-02-20 04:59:20 | Restoring to a certain schema |
Previous Message | Justin Clift | 2003-02-20 04:08:44 | Re: How do I upgrade or coexist PostgreSQL on a Cobalt |