Сортировка запроса при помощи PLAN

[pal]

Правильно ли я понимаю, что указание в плане выполнения запроса конкретных индексов не гарантирует то что резалтсет будет отсортирован нужным образом?
Например, имеем таблицу test с двумя полями a и b и двумя индексами i_a и i_b и пишем
SELECT * FROM test t PLAN (t INDEX(i_b))
или
SELECT * FROM test t PLAN SORT(t INDEX(i_b))

По-крайней мере эксперименты на реальных данных говорят что резалтсет сортируется явно не по указанному в плане индексу. Так и должно быть или у меня что-то с руками?

[dimitr]

если ни черта в планах не понимаешь, то зачем взялся? Сортируют люди через ORDER BY, а не через планы.

[pal]

то что сортировку можно осуществить через order by я знаю и без вас. В данном случае я просто хочу помочь анализатору дабы он выбирал записи в уже отсортированном порядке и не выполнял операций связанных с дополнительной сортировкой данных. Т.е. использвоать план выполнения аналогично хинтам в oracle.

[dimitr]

план выполнения не равен хинтам оракла. И даже там я сходу не вижу, как можно сортировать не сортируя. Что есть уже "данные в уже отсортированном порядке"? Они на диске легли в нужном тебе порядке? Дык значит вообще не надо никакой сортировки. Или нужна сортировка в порядке индекса? Тогда пиши ORDER BY и индекс будет использован.

[kdv]

дабы он выбирал записи в уже отсортированном порядке

по правилам реляционных БД данные хранятся в случайном порядке. Порядок данных указывается при выборке только через order by.
Исключением, когда данные хранятся в упорядоченном по какому-либо критерию, являются например кластерные индексы в MS SQL. Однако стоимость поддержки такого "индекса" весьма высока, поэтому такое решение рекомендуется для очень редко изменяемых таблиц.

В IB/FB, кроме всего прочего, рядом на одной странице данных могут находиться две или более версий одной записи, имея разные значения определенного столбца. Как прикажешь "сортировать" в этом случае, если разным транзакциям допустимо видеть разные версии такого "пакета"?
В общем, dimitr тебе правильно сказал. Лучше сходи, почитай его статью www.ibase.ru/devinfo/dataaccesspaths.htm, а также забей пока на ручное написание планов, пока не поймешь, как действует оптимизатор. Если тебе это вообще надо.

SELECT * FROM test t PLAN (t INDEX(i_b))

уже этот пример показывает, что ты "не в курсе". Индекс сюда нафиг не нужен, т.к. его использование приведет к лишним (!) индексным чтениям.
Если же выборка производится по индексу, то -
1. ключи индекса отсортированы
2. после выборки номеров записей сервер сортирует эти номера, чтобы выбирать записи в оптимальном порядке.
в общем, читай...