Re: poor VACUUM performance on large tables - Mailing list pgsql-performance

From Tom Lane
Subject Re: poor VACUUM performance on large tables
Date
Msg-id 22356.1126055247@sss.pgh.pa.us
Whole thread Raw
In response to Re: poor VACUUM performance on large tables  (Jan Peterson <jan.l.peterson@gmail.com>)
List pgsql-performance
Jan Peterson <jan.l.peterson@gmail.com> writes:
> Based on this, it looks like we could stand to bump up our FSM another
> couple hundred thousand.  Does it buy us anything to reduce the number
> of FSM relations from the default of 1000?

Not a lot; as the comment says, those slots are only about 50 bytes
each.  (I think the true figure is closer to 70, according to some
measurements I did recently on CVS tip, but in any case it's less than
100 bytes apiece.)  Still, a byte saved is a byte earned ...

> It looks like we are using the defaults for work_mem (1024) and
> maintenance_work_mem (16384).  We could certainly bump these up.  Is
> there a good way to determine what settings would be reasonable?

I'd bump up maintenance_work_mem by a factor of 10 and see if it makes a
difference.  It should reduce the number of passes over the indexes when
vacuuming up lots of deleted rows.  If you have lots of RAM you might be
able to increase it more, but try that for starters.

            regards, tom lane

pgsql-performance by date:

Previous
From: Jan Peterson
Date:
Subject: Re: poor VACUUM performance on large tables
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: Poor performance of delete by primary key