Тут возник вопрос по примеру который был выше с джойнами

(https://t.me/clickhouse_ru/343260) , увидел там такое
CREATE TABLE WebhookHubMessageStatuses
(
`Id` Int32,
`Timestamp` Int64,
`IdMessage` Nullable(String),
`Status` Nullable(Int32),
....
INDEX wa_webhook_msg_status_IdMessageStatus (IdMessage, Status)
TYPE set(0)
GRANULARITY 8192
)
ENGINE = ReplacingMergeTree(__data_transfer_commit_time)
ORDER BY Id
SETTINGS index_granularity = 8192;
где у индекса выставлена гранулярность 8192, судя по доке это значит в индексе будет собираться по 64кк (8192*8192) строк. Т.е. фактически блоки скорее всего будут без разбивки идти?
И вопрос как это повлияет на производительность вставки и выборки?

о блин пропустил это, да, индекс бесполезный и ничего не индексирует и скорее всего не используется гранулярность secondary indexes измеряется в гранулах первичного ключа... то есть там должно быть от 1 до 8 в целом. ну иногда 16 и 32 я видел... для очень редких кейсов тем боле что там еще и тип кривой set(0) я бы сделал ALTER TABLE ... DROP INDEX от греха подальше

а в целом не конкретно тут а в общей практике к чему приведет вот такая ошибка в плане производительности7

ну, индекс может пытаться использоваться и использоваться не эффективно потому что в клике индексы это data skip то есть при открытии парта и использовании индекса проверяется что искомого значения НЕТ в парте и поэтому его можно не сканировать... вообще data skip индексы плохо работают если искомые значения колонок размазаны ровным слоем по всем партам тогда получается оверхед на проверки индексов замедляет запрос потому что парты все равно сканируются... ну и когда куча мелких партов тоже будет замедление. но куча мелких партов это в любом случае жопа которую надо чинить со стороны INSERT

т.е. в случае set(0) но такой большой гранулярностью 8192 смысла в нем абсолютно нет, т.к. он будет говорить что среди 8192 гранул есть/нет искомого значения и если есть то он полезет читать эти данные. Т.е. по факту любой срабатывание данного индекса просто приводит к потенциальному чтению до 64кк строк и он реально бесполезен

конкретно set(0) + GRANULARITY 8192 тупо говорит "это значение есть в этих 8192 гранулах или нет" поскольку гранулы тоже не маленькие ... то он тупо проверяет есть или нет значение причем он еще и весить должен дофига, потому что фактически дублирует колонки IdMessage + Status в каждом парте, и я не помню, сжимаются ли data skip индексы или нет...

спасибо, значит все правильно понимаю

если было например set(100) то если у нас больше 100 значений в блоке, то индекс пустой и тупо опять же не используется https://clickhouse.com/docs/en/optimize/skipping-indexes#set

это было проще понять, чем как влияет гранулярность

добрый день, этот индекс я создавал в тщетных попытках оптимизировать запрос и забыл удалить после того, как по EXPLAIN понял, что она бесполезная :) А можно ли в этом кейсе настроить и подобрать правильный skipping index или это в любом случае будет бесполезным?

в каком этом кейсе??? там запрос где с WITH? повторюсь еще раз. эффективность skipping индексов зависит от того, как искомые значения распределяются по партам... если равномерно, то эффективность низкая, если нет. то норм