| OCR Text |
Show ~1 :\!loving objects in a POS which uses physical OlDs is difficult . Changing the object sizP leads to moving obj ects in the store. For ObServer and Postgres which do noL use phys ical O!Ds, t his is not a problem , but fo r ESM, change in object size 1<-·ads to performance cleteriora,t ion as can be seen from the graph for ESM in J·' igurc ."!.::!:). 5.5.2 Variations 5 .5.2 .1 Logging vs. No Logg ing To explain t he exorbitant cost of update for large objects in ESM, one possibility is that tbc~ re is a lot of overhead for logging. ESM allows t he client to cleo·ease the loggitlg ovl·tlwrtd IJ_V logging ot!ly tlw tlWL<J-da.tn rt.tld 110L the d.ctl tal da.L<L. F'igure :i .21l shows t he performance measnrernents for both full logging and partial logging for cliflereot operations. As can be seen, this has a profound effect on update for large objects. !-\ ll upd ates require logging botb the before-image as well as the after-i tTl age. 5.5 .2.2 File System vs. Raw Partition VVlwtt <-l r<-~w disk patti Lion is ttsecl, disk reads and wri tes do not baw~ to go through operat ing system buffers. As a res rtl t , there is perform ance in1provement as can he SPell from Pigure .5 .2.5 and .5.26. 5.5.2.3 Updat e vs. New version It t I ~S l\'1 , <-~ It object. utn lw vnsioned. This involves ''freezing" the old object and <Jssigtti ttg a new OlD Lo tbe uew version. The actual obj ect is copy-on-write shared l)('tween t he original object and t he nevv Vf' rsion . The extra cost in creating and processing OIDs is evident in the Figure .5 .27 |
