Re: poor VACUUM performance on large tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: poor VACUUM performance on large tables
Дата
Msg-id 22356.1126055247@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: poor VACUUM performance on large tables  (Jan Peterson <jan.l.peterson@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Jan Peterson
Дата:
Сообщение: Re: poor VACUUM performance on large tables
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: Poor performance of delete by primary key