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@xxxxxxx] 
Sent: 21. febrúar 2007 22:19
To: rgoulet@xxxxxxxxxx; Laimutis Nedzinskas; oracle-l@xxxxxxxxxxxxx
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

Other related posts: