Есть запрос в IbQuery, через Fields в него добавлены lookup поля. Всего возвращает около 15 000 записей. Работает довольно долго где-то 3-4 сек, может есть какая-нибудь возможность прогружать его постпенно? Тоесть пусть откроет видимые записи в DBGrid(их там 20 вроде), а остальные продолжает подгружать. Ну понятно, если пользователь будет сразу листать вниз пусть тупит, пока все не загрузит...не возбраняется . Думаю в этих компонентах такое нельзя реализовать, может есть какие другие или через возможности SQL такое реализуется.

Вообще сам IBQuery не фетчит все записи. Фетч можно сделать либо как

или 
То есть, если у вас код типа


  То фетч не выполняется. Другое дело, что сам DBGrid может делать фетч. Попробуйте с другим Grid'ом или напишите свой на базе StringGrid.

P.S. Я использую IBQuery + EhLib DB Grid   -  ничего автоматически не фетчится. Попробуйте.

Фетч там делается для некоторых целей, но сейчас есть идеи как от него избавиться. Это конечно сэкономит кучу памяти и времени, но запрос все равно будет выполнятся медленно. Когда последний раз боролся с этим запросом, понял что без "order by" работает намного быстрее: 32ms против 1.5s.  Причем пытался делать сортировку по первичному ключу все бестолку...так же медленно, не очень понятно почему? Из идей при первом запуске вообще отказаться от сортировки, не очень удобно но зато быстро .
Всегда пользовался DbGrid, но хотел бы узнать в чем  преимущества перед ним у EhLib DB Grid?

Почитай здесь



Очень странно. Такое впечатление что сервер сам еле ворочается.

   Показывай запрос и план.

  Красивше он.   

Запрос банальней не бывает . Покажу на примере:
В таблице A примерно 15 000 записей, в B около 100.

Пытался делать через Left join, работает ещё медленне поэтому уж лучше так .

adr - типа varchar. Убирал его и ставил : order by A.i, по времени выйгрыша не получил...зато без него прямо прогресс на лицо.

P.S> Почитал про EhLib, понравилось. А я эту фигню ручками прописывал обычно . Но при закачках написано: EhLib 4.2 Оценочная версия (работает только при запущенном IDE) archive for D5-D9, BCB5-BCB6, BDS2006, Delphi2007. Не понимаю, что такое Оценочная версия и что значит "работает только при запущенном IDE"?

Это сообщение отредактировал(а) pavelv - 20.8.2007, 05:20

Наверно деньгу платить придётся

План запроса!!! 
Для каких-либо выводов нужен план выполнения запроса. Ну, и версию сервера тоже неплохо услышать.

План запроса, не понимаю что ты имеешь ввиду? Для каких выводов, IbQuery связан с DBGrid, в нем всё и отображается. Версия сервера: FireBird 1.5 SuperServer.

Это относится к последней версии. Значит что будет работать, только если программа запущена из Delphi.

А вот версия EhLib 3.6 - бесплатна для жителей бывшего СССР. Подробнее смотри здесь(в самом низу)

 Скачай IBExpert (около 17 Мб), подключи в нем свою базу и открой SQLEditor. Вставь в верхней половине окна свой запрос и нажми "Execute". В нижней половине окна появятся какие-то данные.   Вот эти-то данные хватай и кидай сюда. 

Да эксперт то стоит, как же без него родимого. Сортировка ведется по индексируемому полю:


Тот же запрос выполнил ещё раз(а то совсем долго делался) результат лучше, в дальнейшем такой и оставался:


Банально убираю из запроса "order by" результат:

Какие выводы из этого делают для оптимизации запроса не понимаю, если кто пояснит буду признателен.

P.S> За EhLib спасибо, сейчас с этим разберусь ставлю библиотеку и буду менять большую часть компонентов в проекте на либовские .

Это сообщение отредактировал(а) pavelv - 22.8.2007, 06:51

pavelv, по-моему надо создать индекс для A.adr

хотя... это совет "не подумавши"(у меня от жары моск плавится)

Это сообщение отредактировал(а) Bose - 22.8.2007, 17:51

Индекс есть.

Покажи DDL таблицы А (вместе с созданием индексов), почему-то мне кажется что на поле A.i создано два индекса.

По твоему плану видно главное - последовательность действий сервера, а именно:
  1) объединение потоков (данных из таблиц А и В)
  2) сортировка того, что объединили

Теперь понятно откуда задержки?

P.S. Мне уже просто самому интересно стало, если не затруднит приведи полный код создания этих двух таблиц, всех индексов к ним и точный запрос на выборку.

P.P.S. Про планы есть отличная статья, рекомендую.

Это сообщение отредактировал(а) chand0s - 23.8.2007, 00:02

Не совсем. Я просто не вижу другой альтернативы для действий сервера, конечно сначала он должен найти все записи в запросе, а потом их упорядочивать. Сейчас прочту статью, может станет яснее. Кстати если даже выбросить таблицу "B" из запроса скорость координально не снижается, эдак на 10% помойму. 

Да действительно индексов несколько, а в примере я упорядочиваю по составному индексу из двух полей:

Таблица A:


Вторая таблица мала интересна, ни одного индекса нет...так напишу:


Запросе соот-но:

Как вариант, попробуй с помощью такой процедуры


Погоняй эту процедуру, потом попробуй создать индекс на B.cod и попробуй снова (в новом подключении, чтобы индекс "увиделся"    ), интересно, будет ли разница на твоих данных.

Завтра конечно попробую, только опять же не туда помойму копать начинаем. Я писал, что если даже полностью исключить таблицу B из запроса, тоесть оставить

 То это работает примерно на 100ms быстрее чем с таблицей B, а без order соот-но время попрежнему в десятки раз сокращается. Завтра попробую вместо A.* записать поля явным образом, путем выбора думаю может найти то которое тянет всё вниз .