<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Hi Christopher,</span></div><div><br><span></span></div><div><span>Thanks for your reply.</span></div><div><br><span></span></div><div><span>So there is a significant impact. I was sure about that.<br></span></div><div><br></div> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font size="2" face="Arial"> <hr size="1"> <b><span style="font-weight:bold;">De :</span></b> Christopher Browne <cbbrowne@afilias.info><br> <b><span style="font-weight: bold;">À :</span></b> David TECHER <davidtecher@yahoo.fr> <br><b><span style="font-weight: bold;">Cc :</span></b> Slony Hackers <slony1-hackers@lists.slony.info> <br> <b><span style="font-weight:
bold;">Envoyé le :</span></b> Mercredi 4 avril 2012 21h34<br> <b><span style="font-weight: bold;">Objet :</span></b> Re: [Slony1-hackers] Number of lock for CreateEvents and performance<br> </font> </div> <br>On Wed, Apr 4, 2012 at 2:34 PM, David TECHER <<a ymailto="mailto:davidtecher@yahoo.fr" href="mailto:davidtecher@yahoo.fr">davidtecher@yahoo.fr</a>> wrote:<br>><br>> Hi<br>><br>> I am using Slony 1.2.22. When a createEvents occurs, I noticed that AccessShareLock is assigned on 11700 sequences in the same transaction.<br>> I've got a lot of objects to replicated.<br>><br>> Could the number of objects being locked having when a createEvent ocurs have a impact?<br><br>This isn't a particular surprise...<br><br>Upon creating an event, the slon process needs to capture which<br>sequence values have changed.<br><br>In 2.0, we optimized this to only capture those that changed. In 1.2,<br>all values of all
sequences are captured in sl_seqlog in *every* SYNC<br>(which corresponds to createEvent).<br><br>The improvement in 2.0 means that less data is tracked, though the<br>locking would still occur on the 11700 sequences.<br><br>So all in all, this isn't a phenomenon that I find surprising.<br><br>You'll find that table sl_seqlog is a *very* busy table in your<br>replication infrastructure. 11700 sequences is a mighty lot of<br>sequences to be replicating.<br><br><br> </div> </div> </div></body></html>