On Thu, Aug 4, 2016 at 8:39 AM, Jan Wieck <j...@wi3ck.info> wrote: > Another problem we recently ran into is that after bulk operations, the > queries selecting the log data on the data provider can degrade. A > workaround > in one case was to ALTER the slony user and set work_mem to 512MB. The > work_mem of 100MB, used by the application, was causing the scans on > the sl_log table to become sequential scans. > > The problem is amplified if the tables are spread across many sets. Merging > the sets into few larger ones causes fewer scans. > > > Regards, Jan >
Unfortunately, I've never been able to migrate to a slony user, so slony runs as postgres and my setting are work_mem = 2GB maintenance_work_mem = 2GB So don't think I can test this theory. Also of note, we have 3 sets Same today, just don't see any long running queries where slony has no time to truncate the table, so I'm not clear what is preventing the slony table from being truncated. ( it really sounds like something that Jan has run into before, just a huge table and for some reason the truncate can't complete before another job or request comes in? Even now the slon table is over 12Million and I expect it to be able to truncate/clear in the next 30 minutes or so, but why.. the big bulk operation finishes at 5am, not sure why it takes another almost 6 hours to truncate that table.. Thanks again! Tory _______________________________________________ Slony1-general mailing list Slony1-general@lists.slony.info http://lists.slony.info/mailman/listinfo/slony1-general