@csergey, если оставаться на уровне только сис-админа, то “нет”. Если идти в ДБА, то — “да”, т.к. задачи оптимизации часто требуют перекроить тяжелые запросы или даже реструктуризовать базу.
@Timosha, тут дело в архитектуре. Все таблицы поделены на страницы (pages), это сделано для удобства администрирования. Соответственно, кэш базы (shared_buffers) состоит из этих страниц. Каждое изменение в данных должно быть записано на диск (WAL, последовательная запись), но синхронизация страниц откладывается, т.к. тут запись произвольная. Так вот checkpoint_segments — это то, куда пишется WAL. И он не может быть связан с чекпоинтом, т.к. чекпоинт подразумевает запись измененных страниц (грязных) в их места в файлах таблиц. И кол-во сегментов влияет только на время до следующего чекпоинта, т.е. если их мало, то база будет часто делать чекпоинты и жаловаться. Попробуйте поставить сегменты=3 и дать хорошую нагрузку.
Кстати, максимальный объем записываем данных не может быть больше размера shared_buffers, т.к. смысл чекпоинта в сохранении на диск грязных данных из кэша.
Рекомендую эти слайды для понимания, увы, на английском, хотя и в картинках.
