Имеется виндовый сервер с 12GB памяти. На нем крутится postgresql с базой 1С:Документооборот. 20 пользователей.

Какие настройки postgresql.conf будут оптимальными?

(0) скопипастил
Параметр "fsync"

На производительность PostgreSQL оказывает существенное влияние производительность дисковой системы, поскольку по умолчанию, параметр fsync включен. Это означает, что при выполнении операции COMMIT данные сразу переписываются из кеша операционной системы на диск, тем самым гарантируется консистентность при возможном аппаратном сбое. Обратной стороной этого является снижение производительности операций записи на диск, поскольку при этом не используются возможности отложенной записи данных операционной системы.

 

Повышение производительности возможно при использовании многодисковых RAID-массивов, созданных на основе кэширующих RAID-контроллеров с энергонезависимой кэш-памятью и использования источников бесперебойного питания(UPS). В этом случае задачу по обеспечению консистентности данных при аппаратном сбое берут на себя описанные выше устройства, поэтому появляется возможность отключения параметра fsync и увеличения производительности операций записи на диск.

 

Следует отметить, что увеличение количества дисков в RAID-массиве и объема кеша RAID-контроллера само по себе позволяет компенсировать снижение производительности, обусловленное включением параметра fsync.
Параметр "effective_cache_size"

Работа оптимизатора в PostreSQL 8.2 существенно зависит от размера выделенной PostreSQL оперативной памяти. При использовании PostgreSQL 8.2 при работе с 1С:Предприятием 8.1 рекомендуется увеличить значение параметра effective_cache_size в конфиргурационном файле postgresql.conf. Значение этого параметра рекомендуется устанавливать не менее половины объема оперативной памяти установленной на компьютере.

(0) Есть книжка хорошая "PostgreSQL 9.0 Performance". PDF-версию можно найти в интернете.

Очень важный параметр enable_nestloop=off может как сильно помочь в плане быстродействия, так и _несильно_ повредить в том же плане. На характерных для 1с многоэтажных запросах оптимизатор часто ошибочно использует нестедлупы там где не надо, проявляется это как загрузка процессора сервера долгое время в течение длительного выполнения запроса на относительно небольших объемах данных. Отключение этой опции заставляет всегда использовать более алгоритмически сложные методы, которые заведомо быстрее, чем О(N) у нестедлупов, но в случае маленьких выборок - с относительно высокими накладными расходами.

(0) http://postgresql.ru.net/FAQ_russian.html вот еще инфа

(3) В типовой бухгалтерии БУ при формировании отчетности по основным средствам и ведомости амортизации это наглядно проявляется.

(0) еще нарыл :

shared_buffers
Объём совместно используемой памяти, выделяемой PostgreSQL для кэширования данных, определяется числом страниц (shared_buffers) по 8 килобайт каждая. Следует учитывать, что операционная система сама кеширует данные, поэтому нет необходимости отводить под кэш всю наличную оперативную память. Размер shared_buffers зависит от многих факторов, для начала можно принять следующие значения:
l 8–16 Мб  – Обычный настольный компьютер с 512 Мб и небольшой базой данных  l 80–160 Мб – Небольшой > сервер, предназначенный для обслуживания базы данных с объёмом оперативной памяти 1 Гб и базой данных около 10 Гб.  
l 400 Мб – Сервер с несколькими процессорами, с объёмом памяти в 8 Гб и базой данных занимающей свыше 100 Гб обслуживающий несколько сотен активных соединений одновременно .

work_mem  
Под каждый запрос выделяется ограниченный объём памяти для работы. Этот объём используется для сортировки, объединения и других подобных операций. При превышении этого объёма сервер начинает использовать временные файлы на диске, что может существенно снизить производительность. Оценить необходимое значение для work_mem можно разделив объём доступной памяти (физическая память минус объём занятый под другие программы и под совместно используемые страницы shared_buffers) на максимальное число одновременно используемых активных соединений.

maintenance_work_mem  
Эта память используется для выполнения операций по сбору статистики (ANALYZE), сборке мусора (VACUUM), создания индексов (CREATE INDEX) и добавления внешних ключей. Размер выделяемой под эти операции памяти должен быть сравним с физическим размером самого большого индекса на диске.

synchronous_commit
Включает/выключает синхронную запись в лог файлы после каждой транзакции. Это защищает от возможной потери данных. Но это накладывает ограничение на пропускную способность сервера.
Если вашей системе не критична потенциально низкая возможность потери небольшого количества изменений при крахе системы, но необходимо обеспечить в несколько раз большую производительность по количеству транзакций в секунду. В этом случае можно установить этот параметр в off (отключение синхронной записи).

Интересно. А все эти настройки так же актуальны, если PostgreSQL работает под Linux?

И, вообще, выгрузка базы и загрузка заново в PostgreSQL каким то образом может влиять на оптимизацию данных? Например, дефрагментация индекса и пространства под базу.

2 Худой: Может, причем очень позитивно. http://www.opennet.ru/opennews/art.shtml?num=7745