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/
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 |