>There is no "regular shared locks" in postgres in that sense. Shared locks <br />>are only used for maintaining
FKintegrity. Or by manually issuing a <br />>SELECT FOR SHARE, but that's also for maintaining integrity. MVCC <br
/>>rulestake care of the "plain reads". If you're not familiar with MVCC, <br />>it's explained in chapter 12 of
themanual.<br />><br />>The source code in heapam.c also mentions Point In Time Recovery to <br />>require
loggingthe locks, though I'm not sure why.<br /><br />Thanks for your explanations, now I can see what was confusing
me.<br/><blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left:
5px;">Theproblem with is that we don't know beforehand if a transaction is a <br />distributed one or not.<br /><br
/>Feelfree to write a benchmark to see how much difference the logging <br />makes! If it's significant, I'm sure we
canfigure out ways to improve it.<br /><br /></blockquote>Now that i finally see that multixacts are due only to
explicitshared lock requests or to FKs, I tend to agree with tom's original doubts about the actual impact of the
multixactrelated logging activities. Of course in practice such an impact would vary from application to application,
soit may still make sense for some classes of workloads to avoid multixact logging, assuming they contain no
distributedtransactions and finding an hack to know beforehand whether a transaction is distributed or not... BTW, if i
manageto find some free time to do some performance tests, i'll sure let you know!<br /><br /><br />Thanks again,<br
/><br/> Paolo<p> Chiacchiera con i tuoi amici in tempo reale! <br />
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com