RE: EnterpriseDB

As far as I understand vacuum is like rman except that it is absolutely necessary to run. Simply put vacuum scans all data to get rid of expired record versions (yet another point of view is garbage collection) Isn´t it a bit of a load on the storage system? I remember testing this same thing on Firebird and yes, it took 100%CPU effectively halting the test machine (probably because of all data resided in RAM) When you talk about aggressiveness of PG autovacuum I start thinking how much it costs to balance aggressiveness of vacuuming against redo generation rate.  

Drawback of Oracle(and I believe innoDB) is that it may cost somewhat more to find record versions but there is no problem to clean old versions because of transaction-ordered rollback segment structure. And yes, there is always snapshot too old issue (unless guaranteed retention is set) But I find it less of a problem than the risk of blowing up storage.  

Brgds, Laimis N  

From: Milen Kulev [mailto:makulev_at_gmx.net] Sent: 21. febrúar 2007 22:19
To: rgoulet_at_kanbay.com; Laimutis Nedzinskas; oracle-l_at_freelists.org Subject: RE: EnterpriseDB

PostGreSql has probably the least problem with MVCC". I agree. autovaccum process exists since version 8.1, I believe. Thereis an backgroung jobs that analyzed automatically the table. The aggressiveness of both autovacuum & analyze processed can be confugured (in the configuration file) A drawback of PG is that in case f UPDATE the whole row is coped (to represent the past version of the row), thus generating more REDO than necessary ;(    

Fyrirvari/Disclaimer
http://www.landsbanki.is/disclaimer

--
http://www.freelists.org/webpage/oracle-l