Re: reindex/vacuum locking/performance?

From: "Matt Clark" <matt(at)ymogen(dot)net>
To: "Andrew Sullivan" <andrew(at)libertyrms(dot)info>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: reindex/vacuum locking/performance?
Date: 2003-10-05 11:14:24
Message-ID: LFEIJBEOKGPDHCEMDGNFOEPHCFAA.matt@ymogen.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Bruce Momjian 2003-10-05 13:36:40 Re: COUNT(*) again (was Re: [HACKERS] Index/Function organized
Previous Message Tom Lane 2003-10-05 06:08:31 Re: COUNT(*) again (was Re: [HACKERS] Index/Function organized table layout)