этот параметр напрямую влияет, получается, на скорость селектов.
я тестирую и подбираю. Если большинство запросов спускаются по ключу сортировки и обрабатывают малое количество записей то его надо уменьшать. Обычно не на столько критично влияние.
Постарайтесь выбрать так: посмотрите сколько *подряд расположенных* строк затрагивают наиболее частые / наиболе востребованные запросы к таблице. Выберите index_granularity такого же порядка или (если есть возможность) примерно в 2-3 меньше. Желательно чтобы значение было кратно степеням двойки (так более эффективно читаются данные с диска / из памяти). Т.е. если 90% ваших запросов обрабатывают 1000 подряд идущих строк, то можно попробовать значения 384, 512,768. Чем больше строк в таблице - тем "дороже" использование маленького значения index_granularity. Чем больше всяких "жирных" строк в таблице - тем больше польза от маленького index_granularity. Т.е. если у вас в таблице например сплошные UInt8 - то опускаться с index_granularity ниже 128 скорее вредно чем полезно. До экстемально маленьких значений типа 2/4/8 имеет смысл опускаться только если таблица небольшая (тысячи строк), и в ней лежат всякие жирные значения (типа String в несколько Кб, или агрегатные функции с толстыми состояниями - типа uniqExact / sequenceMatch). Для нормальных таблиц с фактами где количество строк измеряется сотнями миллионов - 8192 хорошо подходит. Т.е. если ваши обычные запросы читают скажем по миллиону строк, то ставить какой-то огромный index_granularity в связи с этим не стоит. Значие по умолчанию - как раз выбрано для таких сценариев. Т.е. подниматься выше этих 8192 обычно не нужно.
Обсуждают сегодня