Базу из FB2.1 перегнали в 3.0. Тестим и оптимизируем запросы. Поэтому вопрос скорее по FB3, хотя в других версиях аналогично.
Есть таблица, есть первичный ключ. Запрос

,
где id_rz - первичный ключ, в IBExpert'е фетчит все записи. Так должно быть? Или это баг/фича IBExpert'а?

Т.е., я так понял, это нормальный механизм, индекс перебирается в одну сторону. Тогда вот такая реальная проблема. Есть таблица:

Выполняю запрос:


или


Всё работает, только есть "перепробег", слишком много переборов. Вопрос такой. Можно ли сделать индекс STAGE_IDX2 типа так:

?
Или обойти эту проблему с помощью других механизмов. Именно к запросу не привязан, потому что код из хранимки.

Пожалуй, апну тему.
Спецы, ау! Разработчики ФБ, ау!
Поведение функции на индексированных полях неправильное. Не должен сервер перебирать все записи. Подозреваю, что min() работает также. Надо что-то делать. Причём срочно.
Это первое. Второе. Что насчёт составных индексов с разным порядком сортировки полей? Есть надежда увидеть?

kdvтоварисч. читай langref на русском языке. можно по 2.5.
А что там написано по этому делу? Это личное дело сервака - как обрабатывать функцию. Вот он неправильно обрабатывает. Это не ошибка, нет. Надо просто изменить подход.
kdvахтунг детектед. сортировка индекса возможна либо только по всем полям asc, либо по всем полям desc. Так что, надежды нет, караул.
А можете по-человечески, без стихов, объяснить почему это сделать невозможно. В других серверах возможно, а в FB невозможно.

kdvKreatorXXIЭто личное дело сервака - как обрабатывать функцию. Вот он неправильно обрабатывает. Это не ошибка, нет. Надо просто изменить подход.
ага. вы там "оптимизируете" запросы, и при этом пытаетесь оптимизировать стыдобу типа max. Оптимизация, кстати, если серьезная, включает в себя и переработку метаданных. Для ускорения запросов.
Ну вот я и прошу подсказать путь, если не судьба поправить радикально. Очень много запросов типа "выдай последнюю дату по этому сотруднику, событию и т.д.", или "выдай то же самое, но для прошлого месяца". Когда всего 5-10 записей на сотрудника, ещё можно закрыть глаза. А когда 5-10 в месяц (не говорю в день), и сотрудников тысячи...

hvladKreatorXXIНу вот я и прошу подсказать путь, если не судьба поправить радикальноDESC индекс чем не устраивает ? Есс-но с DESC в ORDER BY:


Да, так покатило. Спасибо! Видимо, придётся плодить дополнительные индексы.

hvlad, дело не в PK. Первый пример так, для понимания что происходит. Есть составные индексы для поиска по дате, например. Из того, что я выяснил, получается, чтобы найти минимальную дату мне нужен индекс asc, а чтобы найти максимальную дату мне нужен индекс desc. Если используется конструкция between, то можно обойтись одним индексом. Но between не всегда нужен.
Но, честно говоря, не очень понятно, почему нельзя "переместиться" в конец "таблицы индекса" и прочитать предыдущую запись, которая, условно говоря, и будет максимальной?

Видимо, вот это:
авторПо сравнению с другими СУБД у индексов в Firebird есть еще одна особенность – сканирование индекса всегда однонаправленное, от меньших ключей к большим. Часто из-за этого индекс называют однонаправленным и говорят, что в его узле есть указатели только на следующий узел и нет указателя на предыдущий. На самом деле, проблема не в этом. Все структуры сервера Firebird спроектированы как свободные от взаимных блокировок (deadlock free), причем гарантируется минимальная возможная гранулярность блокировок, равная одной странице. Помимо этого, действует также правило "аккуратной" записи (careful write) страниц, служащее мгновенному восстановлению после сбоя. Проблема в двунаправленных индексах заключается в том, что они нарушают это правило при расщеплении страницы. На текущий момент неизвестен способ безблокировочной работы с двунаправленными указателями в случае, если одна из страниц должна быть записана строго перед другой.
Примечание. На самом деле, варианты обхода этой проблемы существуют и они сейчас обсуждаются разработчиками .
Данная особенность приводит к невозможности использования ASC-индекса для DESC-сортировки или вычисления MAX и наоборот, невозможности использования DESC-индекса для ASC-сортировки или вычисления MIN. Разумеется, сканированию индекса с целью поиска однонаправленность никак не мешает.
Радует, что: a) Разработчики знают об этой проблеме, б) Разработчики обсуждают варианты обхода проблемы. Будем надеяться на скорый результат.
Хорошо бы, конечно, вот такие узкие места отображать в руководстве по языку. Потому что у нас сплошь и рядом такая проблема, а проводить тщательный анализ производительности и потребности не было, да и ресурсов (Вот только когда пользователи поставили жёстко вопрос, мы начали шевелиться). Тем более, что в других СУБД всё по-другому.