Каждый процесс - это скорее всего клиентское соединение -
и похоже что проблема в php скрипте или cgi - ты ведб даже не намекнул
что используешь в качестве клиента к PG и причем тут IE :-)
Вот пример тяжело нагруженной машины 8) (
Время отклик для операторов сидящего в 10MБ локалке равен в среднем 3 сек.
В следующем списке операторские форки это только PID 5952 и 3017. Остальные 3 - ядро постгреса - они висят в памяти постоянно 8)
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
5952 postgres 2 0 7160K 3252K sbwait 4:15 8.74% 8.74% postgres
241 postgres 2 0 6344K 0K select 0:13 0.00% 0.00% <postgres>
232 postgres 2 0 6300K 0K select 0:12 0.00% 0.00% <postgres>
240 postgres 2 0 7288K 0K select 0:02 0.00% 0.00% <postgres>
3017 postgres 2 0 7100K 0K sbwait 0:01 0.00% 0.00% <postgres>
Точнее опиши свою ситуацию.

Наверняка знатоки и гуру будут много смеяться... и всеже. :)
Глубоко IMHO я считаю :
1) для баз предназначенных для ползователя www/apache/php/nobodywww
99% запросов которых составляют SELCT-ы можно смело отрубать fsync.
Это дает 1.5-2 выигрыш по скорости. При этом при отключении питания
или падении ОС во время транзакции с UPDATE/DELTE/INSERT можно потерять кой чего. Но я сомневаюсь что сервера у тебя падают очень часто
а критичность данных на сайте такова что от WAL-лога нельзя отказаться.
. 2) Если твои регулярно херишь _в_с_е данные в таблицах (ну разве что окромя справочников) а потом вставляешь здоровенные паки новых данных - то рекомендую после этого делать VACUUM FULL а затем INDEX REBUILD
Хотя если нет времени на VACUUM - в качестве временной меры сойдет и
DROP/CREATE для главных таблиц.
Стоит добавить их в periodic или crontab.
Это должно сдержать нарастание времени отклика запросов после масовых INSERT/DELETE. да и планировщик меньше будет тупить.
3) Пересмотри чем занимается php -скрипт или что-там-у-тебя запускает
апач. Довольно простыми действиями (я постил картинки в базу upload-ом)
можно забить произвольную машину до загрузки 2.0 8))
4) Первая Вырезка из лога - это напоминание что в конфиге прописано конечное
число одновременных подключений. По умолчанию их 32. Определаются
в postgresql.conf и (точно не помню как) при запуске pg_ctl
5) Вторая вырезка это понятное возмущение ПХП недождавшегося отклика
от сервера. Мдас хотелось бы хоть одним глазком глянуть на запрос
натворивший такое. Это случайно не декартово произветдение списков
IP-шников доменов *.org *.com и *.ru?? 8-) Припоминаю как один заказчик
попросил забухать данные для моделирования нагрева листового рулона
в dbf-ник и удивился когда на счет по 100000 узлов потребовалось около 4 часов (правда это было i286) 8))
6) Прошерсти разделы доки администратора по тюнингу - там про многое описано куда подробнее. 8)
7) Если подозрения о какой-то дыре стоит проверив посмотрев баг-репорты по установленным у тебя версиям apache/posmaster/modphp!
Ведь вообще непонятно что утебя за ОС и какие версии/билды постгреса апача и пхп.