Alvaro Herrera <alvhe...@commandprompt.com> writes:
> I wonder if we should have a different mode of operation that only
> attempted the truncate (say VACUUM TRUNCATE), optionally being
> non-conditional about obtaining the required lock. That said, I wonder
> even more whether any such hacks are still needed after the visilibity
> map that changed the landscape for vacuum so dramatically.
Yeah. The one thing in this thread that seemed like a good idea to me
was to bias the FSM code a little bit towards returning space near the
start of the relation, rather than its current behavior of treating all
the free space equally. The current arrangement pretty much guarantees
that you'll never recover from a bloating episode without taking special
manual action. (This is not new to 8.4, the previous FSM code behaved
the same.)
The analogy in the back of my mind is the btree code that decides
whether to split the current page or move to the next page when it has a
full page and a new key that could go to either page. We found out that
randomizing that choice made a *huge* improvement in the average
behavior, even with the probabilities set up as 99-to-1. I'm thinking
that just a small chance of resetting the search to the start of the
relation might do the trick for FSM.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
