> On Sat, Oct 04, 2003 at 12:29:55AM +0100, Matt Clark wrote:
> > My real world experience on a *very* heavily updated OLTP type
> DB, following
> > advice from this list (thanks guys!), is that there is
> essentially zero cost
> > to going ahead and vacuuming as often as you feel like it. Go
> crazy, and
> > speed up your DB!
>
> That's not quite true. If vacuums start running into each other, you
> can very easily start eating up all your I/O bandwidth. Even if you
> gots lots of it.
Very true, which is why all my scripts write a lockfile and delete it when
they're finished, to prevent that happening. I should have mentioned that.
> Also, a vacuum pretty much destroys your shared buffers, so you have
> to be aware of that trade-off too. Vacuum is not free. It's _way_
> cheaper than it used to be, though.
That's _very_ interesting. I've never been quite clear what's in shared
buffers apart from scratch space for currently running transactions. Also
the docs imply that vacuum uses it's own space for working in. Do you have
more info on how it clobbers shared_buffers?
M
