<div dir="ltr"><br><br>On Thu, Aug 4, 2016 at 10:29 AM, Tory M Blue &lt;<a href="mailto:tmblue@gmail.com">tmblue@gmail.com</a>&gt; wrote:<br>&gt; On Thu, Aug 4, 2016 at 8:39 AM, Jan Wieck &lt;<a href="mailto:jan@wi3ck.info">jan@wi3ck.info</a>&gt; wrote:<br>&gt;&gt; Another problem we recently ran into is that after bulk operations, the<br>&gt;&gt; queries selecting the log data on the data provider can degrade. A<br>&gt;&gt; workaround<br>&gt;&gt; in one case was to ALTER the slony user and set work_mem to 512MB. The<br>&gt;&gt; work_mem of 100MB, used by the application, was causing the scans on<br>&gt;&gt; the sl_log table to become sequential scans.<br>&gt;&gt;<br>&gt;&gt; The problem is amplified if the tables are spread across many sets. Merging<br>&gt;&gt; the sets into few larger ones causes fewer scans.<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; Regards, Jan<br>&gt;&gt;<br>&gt;<br>&gt; Unfortunately, I&#39;ve never been able to migrate to a slony user, so<br>&gt; slony runs as postgres and my setting are<br>&gt;<br>&gt; work_mem = 2GB<br>&gt;<br>&gt; maintenance_work_mem = 2GB<br>&gt;<br>&gt; So don&#39;t think I can test this theory.<br>&gt;<br>&gt; Also of note, we have 3 sets<br>&gt;<br>&gt; Same today, just don&#39;t see any long running queries where slony has no<br>&gt; time to truncate the table, so I&#39;m not clear what is preventing the<br>&gt; slony table from being truncated. ( it really sounds like something<br>&gt; that Jan has run into before, just a huge table and for some reason<br>&gt; the truncate can&#39;t complete before another job or request comes in?<br>&gt; Even now the slon table is over 12Million and I expect it to be able<br>&gt; to truncate/clear in the next 30 minutes or so, but why.. the big bulk<br>&gt; operation finishes at 5am, not sure why it takes another almost 6<br>&gt; hours to truncate that table..<br>&gt;<br>&gt; Thanks again!<br>&gt; Tory<br><br>Also interesting today, is that it&#39;s getting worse :) but the same pattern, other then it&#39;s taking longer and today I saw something really weird. <br><br>slon ran a truncate but only cleared 50% of the sl_log1, How is that possible, I mean a truncate is a truncate, I have no idea how this table went from 14M to 7M<br><br>2016-08-04 10:43:03 PDT clsdb postgres 10.13.200.231(37864) 58874 2016-08-04 10:43:03.237 PDTNOTICE:  Slony-I: could not lock sl_log_2 - sl_log_2 not truncated<br><br>2016-08-04 10:53:43 PDT clsdb postgres 10.13.200.231(37864) 58874 2016-08-04 10:53:43.573 PDTNOTICE:  Slony-I: log switch to sl_log_1 complete - truncate sl_log_2<br><br>2016-08-04 11:05:41 PDT clsdb postgres 10.13.200.231(37864) 58874 2016-08-04 11:05:41.750 PDTNOTICE:  Slony-I: Logswitch to sl_log_2 initiated<br><br><b>2016-08-04 11:16:54 PDT clsdb postgres 10.13.200.231(37864) 58874 2016-08-04 11:16:54.783 PDTNOTICE:  Slony-I: log switch to sl_log_2 complete - truncate sl_log_1   &lt;--- didn&#39;t actually &quot;truncate&quot; the table, there is still 7.5M rows and yet it&#39;s moving ahead with logswitch to sl_log_1 (which again was just supposedly truncated, had 14 million rows but has 7.5 Million rows still)..</b><br><br>2016-08-04 11:29:06 PDT clsdb postgres 10.13.200.231(37864) 58874 2016-08-04 11:29:06.332 PDTNOTICE:  Slony-I: Logswitch to sl_log_1 initiated<br><br>2016-08-04 11:40:43 PDT clsdb postgres 10.13.200.231(37864) 58874 2016-08-04 11:40:43.048 PDTNOTICE:  Slony-I: log switch to sl_log_1 complete - truncate sl_log_2<br><br>2016-08-04 11:51:44 PDT clsdb postgres 10.13.200.231(37864) 58874 2016-08-04 11:51:44.660 PDTNOTICE:  Slony-I: Logswitch to sl_log_2 initiated<div><br></div><div>So what I&#39;m also noticing and maybe not related, but my standby node has lots of locks and long running reports, I&#39;m wondering if it&#39;s causing some of the backup seen on the master.  So many questions still :))</div><div><br></div><div>Thanks for listening and being my wall to bounce stuff off of</div><div><br></div><div>Tory</div><div><br></div></div>