> Looked like pg_autovacuum is operating as expected. One of the annoying > limitations of pg_autovacuum in current releases is that you can't set > thresholds on a per table basis. It looks like this table might require > an even more aggressive vacuum threshold. Couple of thoughts, are you > sure it's the table that is growing and not the indexes? (assuming this > table has indexes on it).
Yes I am sure (oid2name :) ). > > And one more question - anyway why table keeps growing? It is shown that > >it occupies > ><10000 pages and max_fsm_pages = 200000 so vacuum should keep up with the > >changes? > >Or is it too low according to pg_class system table? What should be the > >reasonable value? > > > > > > Does the table keep growing? Or does it grow to a point an then stop > growing? It's normal for a table to operate at a steady state size that > is bigger that it's fresly "vacuum full"'d size. And with -V set at 0.5 > it should be at a minimum 50% larger than it's minimum size. Your email > before said that this table went from 20M to 70M but does it keep > going? Perhaps it would start leveling off at this point, or some point > shortly there-after. Yes it keeps growing. And the main problem is that performance starts to suffer from that. Do not forget that we are talking about 100+ insert/ update/select/delete cycles per second. > Anyway, I'm not sure if there is something else going on here, but from > the log it looks as though pg_autovacuum is working as advertised. Something is out there :). But how to fix that bloat? More aggressive autovacuum settings? Even larger FSM? Do not know if that matters but database has very many connections to it (400-600) and clients are doing mostly asynchronous operations. How to find out where this extra space gone? Thanks, Mindaugas ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster