Re: simulating high load for vacuum full - Mailing list pgsql-general

From Bill Moran
Subject Re: simulating high load for vacuum full
Date
Msg-id 20090617072505.3b79ff7b.wmoran@potentialtech.com
Whole thread Raw
In response to simulating high load for vacuum full  (Ivan Sergio Borgonovo <mail@webthatworks.it>)
List pgsql-general
In response to Ivan Sergio Borgonovo <mail@webthatworks.it>:

> I'm trying to diagnose a problem that happened during vacuum full.

What _is_ the problem?

> It is a programming problem triggered by some lock, delay whatever,
> happening during vacuum.

The solution is to fix the lock, delay, or whatever issue.

> Making large updates to a bunch of tables is a PITA just to obtain a
> slow VACUUM FULL.

I don't understand what that sentence is supposed to mean.

> Restoring a "fragmented" DB doesn't look as a working strategy.
> The restore shouldn't be fragmented.

It won't be.

> What are the "side effects" of a vacuum full?

Index fragmentation.  Table locks that block other processes until the
vacuum full is complete.  Heavy disk activity.

> Any cheaper way to cause a heavy vacuum full or just its side
> effects?

Huh?  Are you try to simulate a vacuum full for testing, or are you
complaining about the side effects of vacuum full?

Quite honestly, I can't figure out what your question is or what you're
trying to do.

--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/

pgsql-general by date:

Previous
From: Thomas Kellerer
Date:
Subject: Re: Data merging problem
Next
From: "Mike Kay"
Date:
Subject: used for large media files