По поводу замеров времени выполнения и сравнений с вариантами запросов с аналитическими функциями на ORACLE и выводов что двойной фулскан таблицы лучше одиночного с аналитикой.
Всё это не имеет смысла без снятия трейсов и полного фетча. По трейсам скорее всего будет видно, что двойные чтения упираются в обращения к диску, аналитика — в память или процессор. Что лучше — зависит от конкретных условий, поэтому выводы о том какой вариант лучше мне кажутся некорректными.
Я предочитаю одиночный фулскан таблицы с аналитикой.
В вашем примере в первом селекте индекс вообще не должен использоваться.
И по моему впечатлению вы не сбрасывали кеш между запросами.
У меня замеры такие: 17.989, 15.616, 19.374 и 19.079, т.е. всё достаточно ровно.
Особенности сортировки конечно знать надо, но вот использоваться в боевом коде — ни в коем случае! Именно поэтому все борются с выборками по index_desc, а Вы наоборот их культивируете. И вообще, зачем написана эта статья? ;)
Это понятно. Но есть цивилизованные способы крепления проводки. Если уж делать и выкладывать в качестве пиара компании — надо делать какследует. Можно было вообще всю станцию скотчем к трубе примотать, скотч всего лишь бы держал метеостанцию.
Всё это не имеет смысла без снятия трейсов и полного фетча. По трейсам скорее всего будет видно, что двойные чтения упираются в обращения к диску, аналитика — в память или процессор. Что лучше — зависит от конкретных условий, поэтому выводы о том какой вариант лучше мне кажутся некорректными.
Я предочитаю одиночный фулскан таблицы с аналитикой.
Честно говоря фулскан индекса это нонсенс.
И по моему впечатлению вы не сбрасывали кеш между запросами.
У меня замеры такие: 17.989, 15.616, 19.374 и 19.079, т.е. всё достаточно ровно.