Добрый день!
В рунтайме программа в цикле формирует запросы к БД для заполнения книги в Экселе.
порядка 30тыс селектов разной степени сложности (размерность таблицы 900 на 35).
время выполнения одного запроса 3-10сек. Например такой

select count(id) from sc inner join scf on sc.id=scf.stat_card_id where sc_id!=-1 and (period_id = 20 or period_id = 19 ) and ((( scf.res=21 or scf.res=32 or scf.res=1 or scf.res=31 or scf.res=4 or scf.res=5 or scf.res=6 or scf.res=7 or scf.res=8 or scf.res=9 or scf.res=10 or scf.res=11 or scf.res=12 or scf.res=13 or scf.res=14 or scf.res=15 or scf.res=17 or scf.res=18 or scf.res=16 or scf.res=20) ) ) and (( scf.res=1 ) ) and sc.mode_sc in (0,1,4)

План выполнения такой
Plan
PLAN JOIN (SCF INDEX (SCF_RES, SCF_PERIOD_ID, SCF_PERIOD_ID), SC INDEX (RDB$PRIMARY51))

Adapted Plan
PLAN JOIN (SCF INDEX (SCF_RES, SCF_PERIOD_ID, SCF_PERIOD_ID), SC INDEX (PK_SC))

------ Performance info ------
Prepare time = 0ms
Execute time = 3s 276ms
Avg fetch time = 3 276,00 ms
Current memory = 43 336 744
Max memory = 43 482 792
Memory buffers = 2 048
Reads from disk to cache = 52 484
Writes from cache to disk = 0
Fetches from cache = 5 515 962

FB - SS 2.5.1.26351
Win7(64)
Для доступа к базе используются компоненты FIB.
КОличество записей в SC и SCF порядка 10млн.

Это нормальное (обычное) время выполнения запроса или можно как-то ускорить, чтобы было менее секунды.
Сейчас для расчета такой таблицы уходит порядка суток!

Симонов Денисche_work,

страничный кеш подымай, раз уж у тебя супер. Например до 50K. Не знаю насколько его можно ещё задрать в 2.5, но не больше чем FileSystemCacheThreshold.
Запрос наверное тоже можно ускорить, но я так понял они у вас автоматом строятся
Да, не указывал - настройки сервера все дефолтные.
DefaultDbCachePages - этот параметр?

Dimitry Sibiryakovche_workНапример такой

Это настоящий запрос или "чисто для примера"? В первом случае его формирователю надо
что-нибудь оторвать за условие "(scf.res=21 or scf.res=1) and scf.res=1".
Не нужно отрывать.
Запрос реальный, не "для примера". Есть и более сложные - связь по трем-четырем таблицам inner join, условия для проверки на бОльшее количество строк.
Так построен алгоритм формирования запросов - условия по строке таблицы + условия по графе.
В общем от этого не уйти. Но ведь не это же причина "тормозов" ?
Собственно я хотел узнать: при таких условиях время 3-10 сек - это "тормоза" или норма? Или можно улучшить хотя бы в несколько раз?
И тогда еще попутно вопрос - в толстом клиенте замерял время выполнения этих же запросов. Там время выполнения больше - 10-20 сек, чем в ibexpert-е. Наверное так и должно быть? (работа компонентов FIB? сервера). Или же время должно быть сопоставимо?

Ivan_Pisarevskyche_workТам время выполнения больше - 10-20 сек, чем в ibexpert-е. Наверное так и должно быть? (работа компонентов FIB? сервера).Я тебе страшную тайну приоткрою, в эксперте используются ФИБ-ы. :)

che_workMemory buffers = 2 048
Reads from disk to cache = 52 484Увеличивай первый параметр (научное имя DefaultDbCachePages в конфиге), чтобы второй приблизился к нулю и при этом сервер не вывалился в своп.

Сам сервер обновить как минимум до 2.5.8Спасибо. Проверю

Dimitry Sibiryakovche_workMemory buffers = 65 536
Лучше , но всё равно сравнимо с первоначальным.А ведь тебя специально
предупреждали, чтобы ты не ставил 65536 или любое другое число, большее, чем
SystemCacheTreshold...

С таким отношением, я так понимаю, про селективность индексов и сбор статистики лучше
вообще не заикаться.

Я проверил разные варианты - 8К, 16К, 32К, 64К
Сейчас поставил 64000
Результат:

Симонов Денисche_work,

значит остаётся только переписывать запросы в человеческий вид

Ну и 30000 SELECT запросов в цикле это бред, над архитектурой надо крепко подуматьпонятно, спасибо