Bruce Momjian wrote:
> I am sorry. I see what you are saying now. I missed the words
> "overwriting smgr". You are suggesting going to an overwriting storage
> manager.
Overwriting storage managers don't suffer from unbounded growth of
datafiles until garbage collection (vacuum) is performed. In fact,
there's no need for a vacuum-style utility. The rollback segments only
need to keep around enough past history to rollback transactions that
are executing.
Of course, then the size of your transactions are limited by the size of
your rollback segments, which in Oracle are fixed in length when you
build your database (there are ways to change this when you figure out
that you didn't pick a good number when creating it).
>Is this to be done only because of savepoints.
Not in traditional storage managers such as Oracle uses. The complexity
of managing visibility and the like are traded off against the fact that
you're not stuck ever needing to garbage collect a database that
occupies a roomful of disks.
It's a trade-off. PG's current storage manager seems to work awfully
well in a lot of common database scenarios, and Tom's new vacuum is
meant to help mitigate against the drawbacks. But overwriting storage
managers certainly have their advantages, too.
> Doesn't seem
> worth it when I have a possible solution without such a drastic change.
> Also, overwriting storage manager will require MVCC to read through
> there to get accurate MVCC visibility, right?
Yep...
--
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org
