Спасибо за ответ
> Для начала перейдите на 8.3 - оно реально быстрее!
 Обязательно воспользуюсь, вы не первый кто об этом упоминает.
> Во вторых проверьте, все ли индексы у вас созданы.
 Индексы созданы, я ещё раз упомяну о том, что на нынешнем хостинге, а
не у меня на стенде, этот запрос выполняется за 0.06-0.07 секунды.
>> оперативке и как можно меньше обращалось к внешнему накопителю. Порылся
> Ну при вашем количестве оперативы это нереально!
 При нынешнем количесве ОЗУ на стенде, да. Больше же интересуют
настройки для production - там ОЗУ ожидается 4-8GB. Но не всё для
postgre часть отдастся под сервер приложений на RubyOnRails.
Одновременных конектов будет немного 6-10 mongrel серверов, то есть 20
конектов это с хорошим запасом.
> Выполняйте запрос с EXPLAIN ANALYZE и смотрите вывод.
> Возможно не хватает индексов, возможно, что вам надо просто
> оптимизировать запросы, а не настройки базы.
 Запрос тестовый и индексов хватает, выбран в качестве "тяжелого" для
тестирования именно настроек СУБД.
 Общие рекомендации по разнесению данных и журнала транзакций на разные
накопители, учёл уже. Чем больше RAM тем лучше, оптимизация самой БД не
являтся сейчас приоритетной. Ещё раз повторюсь я использую для
тестирования БД с реально работающего сервера. Каждый раз она создаётся
для тестирования из дампа. Там VACUM -у пока ещё делать нечего. Что меня
интересует это:
1. Рекомендации по настройке буферов памяти при наличии достаточного
объёма RAM для того чтобы вся БД помещалась в памяти. Объём базы около
600Мб реально откусить на сервере можно 2-4Gb только для того чтоб
Postgre не трогал винт при выборках.
2. Имеет ли смысл тонкий тюнинг настроек планировщика запросов QUERY TUNING?
3. Что имеет смысл крутить и в какую сторону для
Background writer. Cost-Based Vacuum Delay. WAL?