1. Доступ к колоночному индексу всегда осуществляется только одним способом: он сканируется целиком (ну, или в рамках партиции, если, сервер понимает, что можно сделать исключение секций).
2. Собственно, поэтому и первоначальная "задержка" - вся таблица подбрасывается в память, если там для этого есть место. И поэтому потом - быстрее.
3. Прелесть в таком поведении, безусловно, есть, т.к. колоночный индекс сжимает хранящиеся данные раз в 8-10, при хорошем раскладе, и, например, если раньше таблица занимала 600Гб, и категорически не влезала в память, даже частями, то теперь - меньше 60 Гб, и влезает туда со свистом. Все запросы ускорились в 100 раз, и это - не фигура речи (из собственной памяти).
4. Да, партиционировать имеет смысл, если в запросах явным образом будет фигурировать ключ партиционирования, ограничивая набор секций, который будет просматриваться.
5. Иногда, партиционировать имеет смысл и по другим соображениям, прежде всего это - массовая загрузка данных в рядомстоящую таблицу, а потом включение ее в основную таблицу в виде секции. Позволяет блокировать основной поток читателей из таблицы не более чем на секунды switch partition. Причем в 2017-19 появилось еще и "ленивое переключение" - можно подождать, пока закончатся все мешающие запросы, а потом - переключиться.
6. Не делить проще, запросы компилируются быстрее, и, если исключение секций в запросе невозможно (или не бывает) - то и выполняется быстрее.

А выделенное не читаем? :-)

msLexво-вторых, columnstore хранится поколоночно, и доступ идет только к данным полей из запроса
в-третьих, внутри columnstore есть справочники, причем как на уровне сегмента так и секции, обращения к которым идет не всегда.
На плане, операции с колоночным индексом всегда присутствуют только в одном варианте: сканирование индекса.
Хотя, в принципе вы правы, правильнее писать: сканирование [i]колонок [/i ]индекса.
Они всегда просматриваются целиком (ну, или в рамках секции, если исключение секций - возможно).

А. Понял. Про это
Не знал, честно говоря. Спасибо.