Здравствуйте, vmpire, Вы писали:

V>Рассматривайте columnstore index как просто отдельную таблицу из ключа и одной колонки.
V>Если у вас полное заполнение этой таблицы, и индекс не covered для запроса, и выбирается большая часть колонок таблицы, то ускорения и не будет.
V>А в вашем случае вообще идёт index scan, то есть, никакой с неко пользы и не получается.
Так вроде columnstore как раз и оптимизирован на indexscan — при indexseek он вообще не используется?

S>>В принципе меня устраивает быстродействие первого индекса (особенно когда выяснил, что оптимизатор может подставлять его в обычный запрос, не использующий вьюшку. Более того — он может подставить даже агрегированный индекс, с суммированием по дням, выдавая 0.057с!),
V>Учтите, что он это умеет в продакшне только в Enterprise версии
Её и используем.

V>Columstore index — это вообще фишка для аналитики. Когда у вас в таблице несколько десятков-сотен колонок, заполненных большей частью nullами. А в выборке участвует только небольшая часть этихз колонок.
V>В таком сценарии columnstore indexes рулят по сравнению с поиском по широченным таблицам.
Ну вот я и пытаюсь понять как их правильно применять.