Дегтярев ЕвгенийMolochnikЭто фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось.
оставим тему про дублирование, я понял что для вас значит усложнение...

вернемся к скорости
в вашем случае выбрать одну запись или 10 по времени одинаково, потому выхлоп будет
но сначала оптимизируйте запрос/структуру (которых мы так и не увидели)
в мсскл у вас та же проблема - 0.5 сек для выборки 1 записи из очереди много
Да, решил разобраться с самим запросом. Отключая разные куски запроса оказалось что проблема в скорости связана с ORDER BY:


tbl1.Priority у всех записей одинаковый, в tbl1 запись одна
tbl2.Priority у всех записей одинаковый, и их в tbl2 50 тыс штук
При объединении таблиц получаются 50 тыс записей у которых tbl1.Priority=0 и tbl2.Priority=0 и по этим полям идет сортировка, которая напрягает оба серверы, но FB особенно. Правда как дальше быть не знаю, поскольку сортировка по приоритету должна быть, он все таки может быть разным. Индексы на оба поля делал но толку нет, значения то одинаковые.

o_v_a... а статистику выполнения реального запроса и
gstat -h
базы мы, похоже, что так и не дождёмся
просто не знал как это делается. Понял сделаю.
Дегтярев Евгенийи все эти 50т требуют обработки?
если нет, то сначала отобрать те которые требуют - после и сортировать до посинения

да нужно именно все записи обработать, может сложиться ситуация когда 49999 записей имеют приоритет 0, а последняя 1, нужно чтобы сначала была обработана последняя запись. Наверное можно сначала выбрать всевозможные приоритеты первой таблицы, затем всевозможные приоритеты второй, потом организовать вложенные циклы c запросом в котором уже не будет ORDER BY по приоритетам. Неужели так и надо делать? Выглядит ужасно криво.
Дегтярев Евгенийи еще вопрос почему задачи не сортируются по одной таблице?

Не совсем понял вопрос, имеется ввиду почему "сортировка по полям разных таблиц а не по одной"? Две разные сущности и каждая имеет приоритет.
Симонов ДенисMolochnik,
я же тебе сразу сказал, что твои * играют злую шутку, потому что план там SORT
Я просто не мог предположить что поле с постоянным значением оказывает такое тяжелое воздействие.

Дегтярев ЕвгенийMolochnik,
это решается соответствующим индексом, но для этого данные должны быть в одной таблице
Может представление сделать? Будет фактически одна виртуальная таблица, но индекс же на ней не построишь, не вариант. Тогда может просто дублировать поля Priority в одну таблицу? И при любом изменении исходных (это случается крайне редко) просто обновлять результирующую по которой и идет запрос?

SiemarglMolochnik,
топик, непонятно чего ты хочешь?
на халяву получить производительность коммерческой дорогой СУБД?
.......
ФБ - простая легковесная штука. отсюда ее плюсы и минусы.
У меня претензий к нему нет, MS SQL тоже же медленно работает, а проблема оказалась в запросе который писал я сам. Если убрать поля приоритетов из сортировки, запрос выполняется обоими серверами мгновенно (5-10 мс)

Старый плюшевый мишкаЕсли приоритетных действительно заметно меньше, есть смысл сотворить индекс по Priority и добиться его использования в QPriority , вплоть до создания композита Priority,ID. И обеспечить его неиспользование в QCommon через +0. Это, правда, может повлечь за собой аналогичную подрихтовку других запросов с условием на Priority.

Касательно в два запроса выглядит криво. Таки нам шашечки или ехать? Ходы кривые роет подземный умный крот, нормальные герои всегда идут в обход проблем.
Выглядит круто, но мне непонятно без примера. Это обработка одного потока, желающего получить одну запись? Тогда почему Priority=1? Потоку же нужен не конкретный приоритет а просто самый высокий.

На текущий момент сделал в основной таблице поле Priority в дополнение к полю NextDateTimeText. Значение в него пишется синтетическое, вычисляемое на основе tbl1.Priority и tbl2.Priority и всегда обновляемое при изменении либо tbl1 либо tbl2. Сделал индекс на основе Priority, NextDateTimeText. Сейчас первая запись, если подходит, ищется около 10 мс на FB. Если дополнительный фильтр по времени запрещает все записи, т.е. худший случай, когда шерстятся все 50 тыс. записей и ничего не находится, запрос длится около 1 сек. Т.е. даже в худшем случае запрос открывается существенно быстрее чем раньше в лучшем случае.

Vlad FMolochnik,
Т.е. все-таки можешь, когда захочешь?))
Так криво же! Лишнее поле, лишние запросы. :) Тут вопрос как дальше оптимизировать чтобы убрать эту 1 секунду на поиск несуществующей записи, видимо циклов с вложенным запросами не избежать.

Симонов ДенисMolochnik,
1. Можно кое что покумекать с CTE для отделения фильтрации и получения первой записи от присоединения дополнительных данных

Думаете, возможно оптимизировать? Вот я попроще оформил эту проблему:

Table1
Id | TaskId | Info|
--------------------
1 | 1 | ' ' |
2 | 1 | ' ' |
3 | 1 | ' ' |
4 | 1 | ' ' |
...| ...| ...|

Table2
TaskId | Condition |
--------------------
1 | 0 |




Симонов ДенисMolochnik,
1. Условия фильтрации можно упростить, да и вообще всякие LIKE нормально не оптмизируются

Я уже немного поправил часть с LIKE:
заменил
иначе без CAST ошибка при непустом :AllowedTexts вылезала. Вообще этот параметр используется очень редко, поэтому LIKE там обычно не срабатывает (т.е. условие всегда True). А вот условие по времени и дате срабатывает часто.

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

да, все так оно и есть
Старый плюшевый мишкаНа что наводит такая штучка как ROWS 1 в тексте запроса. Кстати, такой синтаксис мне незнаком, но я подумал, что либо я не в курсе последних веяний, либо автор привёл запрос MS SQL.

Все придумывают кто на что горазд: TOP, ROWS, FIRST. Стандарта видимо нет.

Старый плюшевый мишкаЭто я тоже неправильно понял из
что 1 - приоритетные строки, 0 - нет. Если есть иерархия приоритетов и основная масса всё-таки с нулевым, отсекаем её в первом запросе по where priority>0 и сортировку оставляем, на небольшом количестве записей она мешать не будет. Во втором уже ни условия на priority, ни сортировки по нему нет - ненулевые поймает первый, до второго дело дойдёт только если он пустой.
Понял вашу логику. Приоритет меняется от 1 до 5 в двух используемых таблицах, думаю больше никому не потребуется, по умолчанию - 3. Обычно да, приоритет не меняют, но если все-таки поменяют, он сразу будет другим во многих записях. Т.е если сделать ускорение только для обычного приоритета, клиент будет недоумевать почему при обычном приоритете система работает быстро, а при критическом тормозит :)

WildSeryROWS - стандарт.
Хорошо бы микрософту об этом сказать