[quote="Tetty]Во-вторых, если не хотите, чтобы пользователи ждали - разбейте на два отчёта. Пусть первый наполнит Z-таблицы в фоновом режиме, а второй лишь выдаст результаты.[/quote]

Пользователи или пользоваль? ИМХО это принципиальный момент в данном решении.

Пользователь или пользователи?
ИМХО, это принципиальный момент в данном решении.

кстати, а есть ли смысл в разбиении на рабочие процессы, если процессор будет один?

Чертов Инет, непоятно запостил или нет.

На суммарное время выполнения будет влиять где один процессор, на сервере базы данных или на сервере приложений.

Но в любом случае будет быстрее. У вас же процессы не с реалтайм приоритетом, поэтому два процесса в сумме получат больше квантов времени на выполнение.

Это верно, если другие процессы тоже будут постоянно заняты. В быстродействии может быть и будет небольшой выигрыш, но память несколько процессов "съедят" значительно быстрее, что может повлиять на общую эффективность.

Может быть узким местом в этих запросах является сетевой интерфейс?
Lexx_nv, а сколько занимает отдельное выполнение SQL запроса непосредственно на сервере базы данных?

Если Ваш рабочий сервер съел памяти столько, что ушел в swap, то это уже не снижение производительности, а катастрофа. Поверьте, все встанет.
А если не используется swap, то что же страшного в большем использовании памяти? Ну использует и использует. Может менеджер динамической памяти (кучи) чуть медленне будет ее выделять-освобождать. Но это копейки.
К тому же базисники должны рассчитать и поставить ограничения на количество выделяемой памяти под процессы и ее максимальный размер, чтобы не допустить остановки сервера.

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

На самом деле согласен, но бывают случаи что и оптимизация запросов не помагает. Например делал я как-то отчетец по регистру материалов в CO, так вроде и индекс брался тот который нужно и условие как нада, но все равно пришлось на параллельную выборку переходить Одним словом если BASIS особо не бурчит то можно использовать, по деньгам выигрыш довольно большой.

Ну, для оптимизации в САПе есть множество узких мест. Каждый конкретный случай надо рассматривать отдельно.

отвечаю
получилось сделать все как хотел
прирост неоспоримо есть
узкое место базеха
я ей кидаю сразу 3 запроса тяжелых в фон
и еще один в программе выполняется
но это быстрее если бы я поочередно выполнял запросы и ждал
выполнения каждого
но наверное главное чтобы запросы не трогали одинаковые таблицы желательно.

все индексы созданы связывал по ключевым полям
но все равно каждый по 4-5 минут\а их 5 штук
вот и думайте

все индексы созданы связывал по ключевым полям
но все равно каждый по 4-5 минут\а их 5 штук
вот и думайте

все индексы созданы связывал по ключевым полям
но все равно каждый по 4-5 минут\а их 5 штук
вот и думайте

А без исходников тут и думать нечего.

а сколько таблиц связываете?
СУБД какая? статистику обновляли?