Добрый день. Помогите понять как работают индексы пропуска в СН.

Документацию уже несколько раз перечитал, но понимание происходящего так и не пришло.
Для тестов использую простую таблицу из 3-х колонок - id (int32), value (int32), dt (datetime). Для чистоты эксперимента таблица создана без ключа сортировки. Естественно, любой запрос к такой таблице выполняет фул-скан. Дальше создаю индекс пропуска на колонку value, материализую его и пробую сделать какой-то запрос с условием на равенство по этой колонке. В результате СН в статистике запроса выводит информацию, что были просмотрены все строки, то есть выполнен фул-скан.
Если выполнить EXPLAIN indexes=1, то сообщается, что будут использованы все парты, но лишь 1/10 часть гранул.
Что не так с созданным мной индексом? Почему сообщается что просмотрены все строки? Почему наличие индекса никак не влияет на это и на скорость выполнения?

Попробуйте сначала создать индекс, а потом залить данные .

Это не всегда возможно. Да и для создания индекса по уже существующим данным должно быть достаточно выполнить MATERIALIZE INDEX, который как раз выполнит его построение. Но ради эксперимента попробую и так

Skip индексы точно будут применяться для новых патров/партиций, а вот для старых. Я не уверен

Я сейчас попробовал создать таблицу, навесить на нее индекс и после заполнить данными - результат тот же - выполнен фул-скан

насколько я понял, это зависит от разряженности данных в партах и собственно их кол-ва на диске?

Ну там есть настройка Granularity, которая отвечает как часто ставить отметки в мета данных столбцов

При создании таблицы используется дефолтная гранулярность и отсутствие какой-либо сортировки, то есть данные сохраняются в порядке их поступления гранулами по 8192 записи. Индекс создается с гранулярностью 10.

Ваша задача уменьшить нагрузку на диск. Если у вас достаточно RAM и не петабайты данных - уменьшайте размер гранулы. Можно и 256 поставить. И коэффициент 2-3 для индекса. Пока не упретесь в размер памяти (индексы там) можно и не повышать.

Да, правильно, стремимся снизить нагрузку на диск. Правильно ли понимаю, что если в первичном ключе не используются колонки, по которым строится индекс пропуска, то этот индекс не будет работать?

неправильно. первичный индекс сам по себе, а дополнительные индексы пропуска - на то они и дополнительные, работают отдельно. Но правильно настроить их под конкретные данные - непросто. У меня получалось некоторое ускорение - полнотекст по википедии работал за 5 сек. Лучше чем ничего, но.....

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

конечно тут совсем не те индексы, которые в транзакционных БД. Это четко сказано в документации. Тут скип индексы. Если брать блум, то это некоторое подобие хешей с большой долей коллизий. Т.е. если вы не попали в первичный индекс и получили фуллскан, то по сохраненным в памяти "типа хешам" можно принять решение что вот эту конкретную гранулу читать не надо - там ничего точно не найти. Но обратное неверно - может и прочитает, но все равно не найдет.

Знаю, что по другому. Но может можете подсказать, как именно индексы пропуска ссылаются на данные на диске, особенно если говорить про тип minmax, как самые простые (как мне кажется)? Если правильно понял, то minmax полностю аналогичен по структуре первичным индексам. И есть ожидания, что будет работать аналогично.

minmax индекс пропуска так работает - в ренже данных гранулярность индекса * гранулярность таблицы такой-то минимум и максимум

первичный индекс основан на сортировке данных на диске. Имея в руках подходящее значение сразу понятно куда делать seek и какую гранулу читать. С вторичным иначе - перед чтением гранулы принимается решение - читать её или нет. В случае minmax в индексе прописаны верхние-нижние значения для конкретной группы гранул.