PostgreSQL: Существует ли практический предел размера таблицы для индекса HA SH? (Индекс HA SH не может быть создан, но другие индексы находятся в пределах минуты) - PullRequest
Новая
       6

PostgreSQL: Существует ли практический предел размера таблицы для индекса HA SH? (Индекс HA SH не может быть создан, но другие индексы находятся в пределах минуты)

0 голосов
/ 19 июня 2020

Я попытался создать несколько типов индексов в одном столбце моей таблицы, чтобы посмотреть, как они сравниваются, все они мне удалось быстро создать, но не индекс HA SH. Я читал о них, как они стали лучше в последних Postgres версиях, но полагаю, что у них все еще есть некоторые ограничения.

В моей таблице 96 477 996 строк, а столбец, в котором я пробовал индексы, является целочисленным. 

CREATE INDEX gpps_brin_index ON cdc_s5_gpps_ind USING brin (id_transformace) WITH (pages_per_range='256');
--27s 879ms
-- drop index gpps_brin_index; 
CREATE INDEX gpps_gin_index ON cdc_s5_gpps_ind USING gin (id_transformace); 
-- 1m 13s
-- drop index gpps_gin_index;
CREATE INDEX gpps_btree_index ON cdc_s5_gpps_ind (id_transformace); 
-- 45s 744ms
-- drop index gpps_btree_index;

Но ха sh индекс не завершился sh даже через 38 минут 

CREATE INDEX gpps_hash_index ON cdc_s5_gpps_ind USING hash (id_transformace);

Я попытался установить рабочую память на 4 ГБ, чтобы посмотреть, имеет ли это значение, но нет change.

Итак, если другие индексы создаются в течение минуты, то, вероятно, что-то не так с ha sh index. Я попытался создать его на какой-то небольшой таблице, и он быстро закончился, поэтому кажется, что есть некоторые ограничения по размеру, когда с определенным размером таблицы индекс начнет бороться. Может ли кто-нибудь подтвердить мне это, или есть что-то, чего мне не хватает.

EDIT: Как объяснил @jjanes, я попробовал индекс ha sh в другом столбце, который имеет только уникальные значения (идентификатор строки ) и индекс HA SH был создан за 2m34s.

PostgreSQL 12.3 на x86_64-p c - linux -gnu, скомпилировано g cc (G CC ) 8.3.1 20191121 (Red Hat 8.3.1-5), 64-разрядная

1 Ответ

2 голосов
/ 22 июня 2020

Допустим, у вас есть 100 различных значений, каждое из которых встречается примерно 1 миллион раз. Таким образом, можно занять только 100 ведер. Как только у каждого id_transformance будет свой сегмент, то независимо от того, сколько раз вы разделите сегмент, все строки будут следовать одному пути разделения и снова окажутся в том же сегменте. Таким образом, у каждого занятого сегмента будет длинный список страниц переполнения. И я не думаю, что есть быстрый путь к концу такого списка, вам нужно проходить его каждый раз, когда вам нужно добавить запись в конец.

Таким образом, вы получаете дегенеративную производительность сборки когда у вас есть большое количество строк, но с небольшим количеством различных значений. Это не общая проблема с большими таблицами, но c специфична для этой ситуации.

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

...