запрос- смотри соседний тред, мы его там обсуждали.
Гммм ... с учетом накладных расходов на передачу данных из системного кеша приложению, нет у меня уверенности, что передача кеширования винде повысит эффективность. Надо проверить. Хотя кеш у файрбирда странный какой-то. Когда у меня было всего 1Г на сервере, а БД - порядка двух или трех гиг, я интересные эксперименты проводил (о чем писал полгода назад). Суть такая:
идет большая пачка запросов на добавление данных в БД. Причем каждый запрос на добавление сопровождается поиском дублей по куче критериев. Стартуем с чистым кешем и не пустой БД, по мере добавления производительность растет (за счет засасывания страниц в кеш). И растет она до момента заполнения кеша у файрбирда (видно по размеру физически выделенной ему памяти). Как умный мальчик я устанавливал количество страниц в кеше файрбирда таким, чтобы еще немного памяти оставалось системе и не начинался ненужный своп. Пока один раз не промахнулся. И вот что выяснилось - разрешив файрбирду использовать 2Г памяти (т.е. вытеснив кеш файрбирда в своп) я получил большую производительность, чем ограничив кеш размером реально доступной памяти. Т.е. алгоритмы кеширования файрбирда были менее эффективны,чем алгоритмы кеширования виртуальной памяти у винды.
Параллельное выполнение запросов
если мне не изменяет склероз - сервер очень плохо отдает тики при сортировке в памяти и индексном чтенииpticelov писал(а): кеш уменьшить можно, если уменшить до состояния, когда пойдут запросы к диску, думаю, починится параллельное выполнениеНо зачем мне снижать производительность?
если идти по табличке натуралом, то при большем времени запроса для конкретного пользователя получаем лучший отклик для остальных
было одной из причин борьбы с индексами - кроме стандартных, от констрейнтов, у меня в базе не найдется и десятка индексов
ищи order by