Re: simulating high load for vacuum full

From: Bill Moran <wmoran(at)potentialtech(dot)com>
To: Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: simulating high load for vacuum full
Date: 2009-06-17 11:25:05
Message-ID: 20090617072505.3b79ff7b.wmoran@potentialtech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

In response to Ivan Sergio Borgonovo <mail(at)webthatworks(dot)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/

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Mike Kay 2009-06-17 12:12:57 used for large media files
Previous Message Thomas Kellerer 2009-06-17 11:15:57 Re: Data merging problem