<br /><br /><b><i>Tom Lane <tgl@sss.pgh.pa.us></i></b> ha scritto: <blockquote class="replbq" style="border-left:
2pxsolid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> paolo romano writes:<br />> The point i am
missingis the need to be able to completely recover<br />> multixacts offsets and members data. These carry
informationabout<br />> current transactions holding shared locks on db tuples, which should<br />> not be
essentialfor recovery purposes.<br /><br />This might be optimizable if we want to assume that multixacts will never<br
/>beused for any purpose except holding locks, but that seems a bit short<br />sighted. Is there any actually
significantadvantage to not logging<br />this information?<br /><br /> regards, tom lane<br /></blockquote><br />I can
seetwo main advantages:<br /><br /> * Reduced I/O Activity: during transaction processing: current workloads are
typicallydominated by reads (rather than updates)... and reads give rise to multixacts (if there are at least two
transactionsreading the same page or if an explicit lock request is performed through heap_lock_tuple). And (long)
transactionscan read a lot of tuples, which directly translates into (long) multixact logging sooner or later. To
accuratelyestimate the possible performance gain one should perform some profiling, but at first glance ISTM that there
aregood potentialities.<br /><br /> * Reduced Recovery Time: because of shorter logs & less data structures to
rebuild...and reducing recovery time helps improving system availability so should not be overlooked.<br /><br /><br
/>Regards,<br/><br /> Paolo<br /><p> Chiacchiera con i tuoi amici in tempo reale! <br />
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
