>>>>> "MTO" == Matthew T O'Connor <[EMAIL PROTECTED]> 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... ;-) ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
