и heap organized tables в базах.
загуглил, написано, что в postgres heap organized tables, и если хотите, можно clustered сделать, но делается он на основании индекса.
Вот хочу спросить....
если уже есть индекс, на основании которого кластеризуется таблица, есть ли существенный профит?
т.е по скорости выборки, вроде как...хотя опять же, не факт.
т.е кто-то юзает активно их?
Причем, есть же тема, что можно создать индекс с включением полей необходимых, чтобы Index only scan был...
в постгресе в clustered таблице записи просто упорядочены по ключу индекса без дальнейшего поддержания порядка. > если уже есть индекс, на основании которого кластеризуется таблица, есть ли существенный профит? профит как и у всех кластеризованных индексов - ниже цена (seq_page_cost вместо random_page_cost) при сканировании нескольких смежных записей по индекс скану
я просто пытаюсь понять, в чем будет разница, если я например создам индекс с включением необходимых полей, которые мне будут нужны в выборке? т.е зачем именно таблицу кластеризовать... Т.е общая суть ясна, упорядочить хранение tuples. но для этого индексы есть. окей...индексы есть, а если данные захотим получить, не обращаясь к таблице? - просто создаём индекс с включением требуемых полей. Т.е я бы понял, если бы таблица кластерилизовывалась без создания вторичного индекса, например. Тогда был бы профит, что можно место сэкономить на диске. А так всеравно отдельно индекс создать надо... Ещё и поддерживать кластеризацию таблицы нужно... Я просто на практике как то не применял кластеризацию таблиц и вот пытаюсь понять, где оно реально применимо, где другие подходы не сработают?) Наверное, где применяются hdd диски и последовательное чтение упорядоченных данных требуется, типа where id between 10 and 500....? Просто в век ssd и nvme, наверно не так важна кластеризация таблиц?
Покрывающие индексы больше по объёму, аффектятся при обновлении покрывающих атрибутов. Потом не всегда index-only scan работает только с индексом - иногда достаётся строка из heap-таблицы для проверки видимости индексного указателя в рамках текущей транзакции, в худшем случае IOS может деградировать в полноценный index scan. А так, да, кластеризованная таблица по предназначению сходна с покрывающим индексом для целевого набора атрибутов в запросе. > Наверное, где применяются hdd диски и последовательное чтение упорядоченных данных требуется, типа where id between 10 and 500....? да, и нагрузка как правило read-only. > Просто в век ssd и nvme, наверно не так важна кластеризация таблиц? разница между последовательным и случайным сканированием всё равно будет. Правда, не такая существенная как у hdd
В MSSQL почти всегда выгодно кластеризовать по PRIMARY KEY (по индексу, который уникальный, недлинный и используется чаще остальных). Доступ по этому индексу станет быстрее, а по остальным столько же. Вторая гипотеза следует из того, что доступ из secondary индекса всегда непрямой. Т.е. heap organized tables в MSSQL они на самом деле тоже index organized по индексу ROWID.
Обсуждают сегодня