dimitrТаблоидМожет, в сильно-конкурентной средеили просто когда база не влазит в кеш :-)Дык у мну в ФБ-3 кеш 512к, я не вижу в трейсе reads>0.

kdvТаблоидМожно, ес-сно. Но только если объем записей для SORT'a не очень большой.
как показывают мои тесты, даже при миллионах записей PLAN ORDER получается хреновее из-за disk io вместо plan SORT. Который выдает результат за N секунд, а не сразу, но зато навсегда.
- - -
если что, рекомендую перечитать
http://ibaseforum.ru/viewtopic.php?f=4&t=4175 Да, я читал её. И перечитал только что снова :-)
Там речь идёт о сравнении ORDER vs SORT для источника данных кардинальностью 14 млн строк. Такие объемы вряд ли перелопачиваются в OLTP-среде. У мну в текущих настройках для одного документа будут перелопачены 50 * 15 * 2 = 4500 строк - и это только в самом худшем случае. Длина записи таблицы (её имя: QDistr), в которой идёт это - 42 байта.

Хотя, один из индексов в ней действительно с не самой лучшей селективностью, но PLAN ORDER был как раз НЕ по нему, а по другому:
TAB_NAMEIDX_NAMELAST_STATCURR_STATDIFF_STATLAST_DONEQDISTRPK_QDISTR5,87758165693231E-75,87233557780564E-75,24607912666397E-1026.07.2014 22:42:14QDISTRQDISTR_DOC_SND 5,85617226533941E-6 5,85370435146615E-62,46791387326084E-926.07.2014 22:42:14QDISTRQDISTR_SNDOP_RCVOP_SND_ID_DESC5,38363792657037E-65,38022004548111E-63,41788108926266E-926.07.2014 22:42:14QDISTRQDISTR_SND_ID5,85610359848943E-65,85366979066748E-62,43380782194436E-926.07.2014 22:42:14QDISTR QDISTR_WARE_SND_OPTYPE 0,000500000023748726 0,000500000023748726026.07.2014 22:42:14
И вот этот индекс, по которому идёт навигация, он-то как раз с хорошей селективностью.

Хотя она у него такая "хорошая" за счет второго поля (там составной ключ: doc_id, snd_id). По первому полю
- возвращает гадость: 0,016215913.

Это похоже на пример из статьи:kdv

Если навигация по индексу с плохой селективностью (а для составного индекса - с плохой селективностью "префикс"-полей) всегда тормозит, то сиё очень плохо. Потому что как только мы добавим в таблицу какой-нить составной индекс, оптимизатор может запросто выбрать его, в т.ч. для PLAN ORDER'a. И - "куку" :(

Согласен вот с этим:автор4. для небольшого количества записей "стоимость" сортировки на диске или выборки в порядке индекса может быть одинаковой.- но увидел это в своём тесте только для 2.5. А вот для 3.0 разница оказалась очень серьёзной, в пользу PLAN SORT'a. База та у мну сохранилась, её саму и примеры я высылал dimitr'у.

PS. К сож-ю, в этой статье не сказано про влияние на время сортировки значений TempCacheLimit'a и TempBlockSize (впрочем, были ли они тогда, в 1.5 ?).

PPS. И еще. Полуофф (?).
Зачем тут говорится про то, что "недофетчили, оттого и быстро":kdvВторой запрос, с выборкой в порядке индекса B, несмотря на мгновенность выполнения выдает только часть записей в grid, поэтому то же самое считывание страниц и их вытеснение из кэша может начаться по мере того, как пользователь будет нажимать в grid кнопку PageDn (или стрелку вниз).- ?
Ведь ясно же, что такое сравнение некорректно и надо было сразу Shift-F9 жмякать :-)

Симонов Денис1. Я запускал твой тест и там с точностью наоборот. Навигация оказалась быстрееЧисло коннектов-молотилок + сколько ты дал времени им поработать перед тем, как сравнивать ?
(и как сравнивал: просто добавил/убавил "+0" из той ХП и перекомпилил её ?)

Симонов Денис2. Про недофетчили. В гридах дельфей это очень частый режим.Я знаю. Но у мну нет тут гридов :-)
Есть ХП, которая, вместо возврата строк в грид, должна обработать эти строки в опр. порядке, причём обязательно все .

Симонов ДенисГде то в fbdevel ДЕ рассуждал о подсказках оптимизатору.Один и тот же запрос с where f = :x будет молотить разное кол-во строк при разных :x, т.к. данные всегда могут быть перекошенными.
Без гистограмм распределения значений сколько не подсказывай оптимизатору, толку большого не будет.

Симонов Денис
эквивалентен
При наличии индекса по ID. Но второй мне как-то более понятным кажется.

Гаджимурадов РустамТаблоид> Без гистограмм распределения значений сколько
Таблоид> не подсказывай оптимизатору, толку большого не будет.

С чего это вдруг? Это смотря какие хинты и как реализовать.Ну так если оптимизатор будет знать распределение данных и НЕ будет составлять план параметризованного запроса заранее, до получения конкретного значения параметра, то... зачем тогда вообще хинты ? :)

dimitrесть куча запросов с непараметризованными предикатами. Классический пример: WHERE IS_DELETED = 0 AND blah-blah-blah - тут тебе и константа и охрененный перекос в распределении.я видел эти дебаты по поводу подсказок (летом в прошлом году они были ?), но что там решили в итоге - не дочитал. Искать в fb-devel'e невозможно, в почте яндекса (куда мне идёт пересыл) - тоже.
Хинты - зло. Рано или поздно они устаревают ввиду изменений в данных. План должен быть другим, но не становится таковым.
Даже с изменением PLAN ORDER на PLAN SORT (добавлением "+0") - возможна ситуация, когда надо будет вернуть всё взад. Я уж не говорю про всякие искуственные замены inner join'ов на left join'ы, воткнутые в авральном порядке, "чтобы сейчас хоть как-то работало, а попозже обязательно разберёмся" (ога, ну-ну...).

Если будет какая-то возможность отследить (трейсом ?) запросы, идущие с хинтами, то это еще ладно, фиг с ними. Но если хинты будут проскакивать мимо всяких средств отслежки, то это бомба себе под табуретку.

Симонов Денисне в случае двух обсуждаемых типов хинтовчто именно "не в случае" ? Думаешь, не понадобится отлов таких вариантов запросов (с ALL_ROWS | FIRST_ROWS) ?