Markus,<br /> I was re-thinking about what you said. I feel, if we read the WAL through archiver(Where the
archiveris switched on), which anyway reads the entire WAL Log, it might save some CPU cycles off updates, inserts and
deletes.<br /> The question is about reducing I/Os and i have no doubt about it. But if we create the WAL Log in
aseperate disk and we make the Vacuum scan through it(in case the archiver is absent), it would reduce the I/O off the
diskcontaining the data. Essentially the I/O effects are seperated. We might end up doing more I/Os, but it would not
affectthe OLTP transactions. <br /> I would also like to clarify one more thing. I am not asking to remove the
DSMapproach. But i am just thinking of creating the DSM by reading through the WAL Logs, instead of asking the Inserts,
updatesand deletes to do the DSM creation. <br /> Of course, if a person places both WAL logs and Data files
inthe same disk drives, this would reduce the performance. But can we take that hit?<br /> I think what Gregory
iscoming at is, "if we schedule the Vacuum after 20% of table changes, then we essentially say we need 120% of the disk
spaceand hence our select operations might end up doing more I/Os." <br /> Please put forward your
suggestions.<br/><br />Hi All,<br /><br />Essentially concluding<br />a) If there is a archiver running, we are putting
slightlymore CPU cycles on the archiver to help form the DSM.<br />b) If there is no archiver, if the DBA places the
WALin a seperate disk, Vacuum will do more I/O on that disk to form the DSM. <br />c) In case someone has not schedules
botharchiver and is not ready to spare a disk for WAL, this approach reduces the performance of that setup.<br />
Aremy conclusions right?<br /> If they are right, how much percentage constitute the third part? (Field experts out
there!!)<br /> If the percentage is more, we should stop this line of thinking.<br /><br />Thanks,<br />Gokul.<br
/><br/>