Postgresql

Какие именно? Для какой платформы? Какое железо (хотя бы проц, объем озу), что еще крутится на сервере, кроме 1С-SQL? В общем, в вопросе слишком мало информации, чтобы на него ответить ;-)
Для начала http://wiki.etersoft.ru/PostgreSQL/Optimum?show_comments=1
И, что очень важно для производительности, перенесите каталоги pg_clog и pg_xlog на физически другой винт, как минимум на тот, где крутится система Нет-нет, именно на другой, отдельный, это я лажу брякнул (база, надеюсь, на отдельном винте?), или на третий. И вообще, в инете много полезной информации, даже далеко ходить не надо - http://infostart.ru/public/89592/, см. раздел 3.2.
Не мешает до и после изменений запускать тест Гилева - он хотя бы ориентировочно покажет изменения в производительности.
Не забудьте только сделать резервную копию postgresql.conf.

Удачи!

Вдогонку: http://cloud.github.com/downloads/le0pard/postgresql_book/postgresql.pdf
Классная книга с примерами настройки, ее здесь уже советовали.

а по статусу официальной поддержки постгреса не подскажете ? т.е. при появлении заплаток на субд патчи от 1с насколько оперативно выходят + поддержка официальная по проблемам 1с на постгрес насколько оперативно реагирует.

:) Зачем Вам настройки Postgre? Вы и так его настраиваете через интерфейс 1С. Конкретно - настройка индексации и права пользователей. Что еще нужно настраивать на этом недоSQL-сервере?

а погуглить, в инете куча готовых инструкций по настройке Postgres

По теме. Вот пример настроек (лишь самое основное) для 16 GB RAM (я это уже писАл в соседней теме, просто может, кому-то пригодится).

effective_cache_size = 6GB #если сделать больше, начинает использоваться своп, что сильно замедляет работу
shared_buffers = 2000MB
max_connections = 120
maintenance_work_mem = 360MB
work_mem = 16MB
wal_buffers = 16MB
checkpoint_segments = 24 #если рэйд с батарейкой, то можно и 32, но ни в коем случае не больше
default_statistics_target = 100
checkpoint_completion_target = 0.9
constraint_exclusion = on
#ну и 1С-специфические настройки:
escape_string_warning = off #чтобы лог не засорялся соответствующими предупреждениями
standard_conforming_strings = off
join_collapse_limit = 1

Аргументированная критика приветствуется. С этим настройками СУБД обслуживает 10-20 пользователей, которые работают с почти 50-ю базами (бухгалтерия и зарплата). На тормоза не жалуются. Оптимизация производилась с целью недопущения использования swap и более полного использованием ОЗУ.

как показала приктика настройка Postgres сводится к изменению количества памяти в effective_cache_size - 2/3 от общего обьема оперативки установленной на компе, все остальные движения к желаемому результату не приведут. только время потеряете.

Не все так просто, к сожалению. Есть рекомендации ставить даже 3/4, но это только если postgre - единственное приложение на сервере. А у нас есть еще 1С, а в перспективе - еще и апач (БП ред. 3.0 уже вышла!).

Подумаем насчет effective_cache_size. 2/3 от 16 GB - это примерно 10-11 GB, и это была именно та величина, с которой начались тесты. Однако, как известно, данные кэшируются не только СУБД, но ОС, и, отдавая СУБД 2/3 оперативки, мы очень мало оставляем не только 1С (а этот процесс тоже кушает память прилично), но и операционке, следовательно, потери производительности будут неизбежны. Иными словами, при больших значениях этого параметра неизбежно будет возникать двойное кэширование - и СУБД, и ОС!
Отсюда - рихтуем настройки самой ОС, в /etc/sysctl.conf:
vm.swappiness=0
vm.overcommit_memory=2
Первая предотвращает возможность использования свопа, вторая - в сущности, говорит ОС, что оперативка будет постоянно забита до отказа, и вероятность, что в реальности в ней будет свободное место, практически нулевая.
Вот только что попробовал тест Гилева с effective_cache_size=4GB, 6, 8 и 10 GB. Результаты: 21,49; 20,96; 20,83 и 20,75. Т.е. почти что нет влияния, но при длительном аптайме (два-три дня интенсивной работы) при 4-6 ГБ производительность не снижается, а при 8-10 - начинает падать.

P.S. А потом взял и выставил effective_cache_size=4GB и fsync=off (только для теста, разумеется, потом все вернул на обратно!). В итоге - 38,46 попугаев. Вывод: основная часть производительности теряется на WAL и несколько улучшить ситуацию можно, разместив его на RAID0 (аппаратном!) или, лучше, RAID10. Как вариант - SSD, для WAL это идеальный вариант с точки зрения щадящего использования (данные только дозаписываются в конец). Но цена хорошего SSD сравнима с 4 винтами WD RE по 250 ГБ, так что вот так вот :-)

PPS Ладно, вот скоро приедет память 4*8GB, еще поиграться можно. 32 ГБ уже сравнимо с объемом наиболее часто используемых баз, так что тут производительность должна существенно возрасти.

Удачи!