Winnipuh
2. Как только в терминале в psql я выполняю команду select count(*) from xprop
сразу вижу как приложение чуть ли не останавливается и после того как команда выполнена - продолжает вставлять.

Гуру, ваши коментарии? ....
Где, что и как улучшить?
Я не гуру, но посмотреть могу (с) почти из анекдота.
Очень, очень ФАКовый вопрос. SELECT count(*) FROM bigtable - есть зло для PG.
По скольку ФАК+поиск это слишком тяжело, то в кратце: сделать отдельную таблицу которую триггерно на INSERT обновлять и брать значения оттуда.

Winnipuh
это я (уже ;-)) понимаю, я count(*) выбрал в качестве примера.
Оно то зло, но не до такой же степени, чтобы сервер тормозил и все клиенты ждали? ...
А если я я буду делать обычный селект, тормозов не будет?
Если будет 100 коннектов? ..
Ну пример - так себе. Он малость непоказателен. На самом деле - он делает всего лишь seqscan по таблице. А дисковая наверняка сильно загружена - вот все и тормозит благодаря "дерганью" диска. Благодаря непрерывным модификациям файл/таблица не эффективно кешируются (ИМХО).
Обычный селект, т.е. SELECT 1+1 - тормозить не будет. более сложные - смотреть нужно, планы изучать, моделировать.
100 коннектов SELECT 1+1 - скорее всего тоже не будут. 100 коннектов бывают разные. Если это будут клиенты каждый из которых множественно с блокировками будет делать перерасчет на 1 минуту (в выделнном режиме), то 100 таких конкурентных транзакций будут требовать хорошего сервера и тащательной продумки архитектуры.

ЗЫ А на практике - моделировать нужно. Ибо есть мелочи которые могут вылезти лично у Вас при масштабировании в которые никто раньше не упирался. Например - выпадение таблицы из кеша из-за его нехватки, "кривые" seqscan'овые запросы и т.д. Т.е. оценки будут из серии "лечить по фотографии", и могут быть весьма далеки от Вашей практики. ИМХО.

В догонку - вспомните свой пост про первый и последующие запуски поиска с использованием индекса. 1-й 2 минуты, 2-й 2 секунды.
Если у Вас хватит мозгов ( в смысле оперативной памяти) на "правильный" кеш - то будет счастие. Если все 100 клиентов будут винт дергать - ИМХО может и сдохнуть нафик. Тут даже скази не поможет

Winnipuh2 Andrey Daeron
спасибо....

Незачто :)

Winnipuh
в том то и вопрос, можно ли надеяться на PG для работы 100-300 коннектов
Вопрос хардваре не стоИт, хорошие серверы будут куплены.

Блин, ну что я могу сказать - есть средства аффтоматизации тестирования нагрузки. Берем и нагружаем. Сильно нагружаем. Еще сильнее. Наблюдаем, рисуем графики. Прогнозируем объемы. Сводим все в месте и получаем ответ.
Примеры использования на афигенных объемах и сложных БД есть. Примеры - сайт самого постгреса (вместе с поисковыми технологиями) и еще куча всего озвучено было на форуме.

ЗЫ А медленно - там же индексов немеряно?

Winnipuh
не так много, но длинные строки полнтекстово индексируются.
Буду в Киеве - с меня пыво. ;)
Ну вот я и думаю, что очень много времени идет на построение (возможно перстроение иногда) этого полнотекстового индекса.

ЗЫ А на тесты внятные было бы очень интерестно взглянуть. Не так много людей на этом форуме имеют 100-200 коннектов к БД.
ЗЗЫ А пыво это можно