Re: Buglist

>>>>> "MTO" == Matthew T O'Connor <matthew(at)zeut(dot)net> writes:

MTO> <talking beyond my real knowledge>
MTO> Changing Postgres to perform as mentioned above is non-trivial, it would
MTO> basicially change the entire core of the system. I think this is due to
MTO> the fact that postgres uses a non-overwriting storage manager. This has
MTO> many benefits including MVCC, the primary disadvantage is that you need
MTO> a vacuum type process
MTO> </talking beyond my real knowledge>

I'm not promoting any change in the MVCC. What I'm saying is that it
would be really cool if the backend process itself could recognize
that a row is no longer referenced by any transactions upon
termination of the transaction, and release it back to the system.
This is just what vacuum does but in a batched manner. I would love
to see it incremental. This would result in pretty much near zero
internal fragmentation, I think.

How hard that is, I have no clue. Right now my DB is saturating the
disk and having to squeeze vacuum into a saturated disk bandwidth is
not pleasant. Luckily, the 14-disk raid array just
arrived... hopefully that will have higher bandwidth than the 4-disk
array... ;-)