теперь запросы с фильтрацией по этой колонке занимают 10 секунд вместо 30, вроде всё хорошо.
но обратил внимание, что из этих 10 секунд 6 тратится на то, чтобы план построить (столько времени занимает, если вызвать этот же запрос с explain indexes=1)
для индекса: secondary_indices_compressed_bytes = 180 килобайт
secondary_indices_marks_bytes = 116 килобайт
как бы посмотреть, во что движок упирается при скане этих килобайт, что тратит 6 секунд на это?
se(20) дорогой индекс
а по каким-то параметрам можно определять дороговизну индекса, кроме того, что по итогу он медленно работает? я вот понадеялся на итоговый размер индекса и меток
Ну размер индекса хороший показатель
у меня сейчас 180 килобайт на 7 гигабайтную таблицу а величина N сильно влияет на перформанс? допустим, если в грануле 5 уникальных значений, Set 10 и Set 20 будут одинаково работать?
> 180 килобайт Ну это фигня, сомнительно даже Вы материализацию индекса сделали кстати?
наверно, это наш data инженер делал вчера, но вообще эту строчку в пулл реквесте я видел ) вообще explain indexes = 1 выдает, что индекс успешно используется (большиство гранул скипается), но проблема в том, что сама генерация этого плана занимает 6 секунд
можете выполнить запрос с set send_logs_level='trace';
https://pastila.nl/?0182265a/38d12cf77c9efc89af22ad185952b538
Обсуждают сегодня