Ярослав, добрый вечер! Удалось пообщаться с Федором Сигаевым (напомню, что

Question

Ярослав, добрый вечер! Удалось пообщаться с Федором Сигаевым (напомню, что

это разработчик GIN индекса) касательно ограничений на maintenance_work_mem при CREATE INDEX для GIN (далее речь пойдет только о данном типе индекса), результаты весьма интересные:
1. Начнем с простого — гарантированно CREATE INDEX отработает при maintenance_work_mem не более чем 12GB;
2. Когда я уперся в INT_MAX, как оказалось, речь, в целом, шла не о кол-ве выделенной памяти под CREATE INDEX, а о размере posting list для конкретного частотного слова, то бишь кол-во ссылок на данное слово (право, есть грех, у меня присутствует частотное слово которое встречается более 2ккк раз, на досуге надо будет обязательно от него избавиться);
3. Таким образом, если бы частотного слова не было, то процесс бы успешно завершился, не смотря на то что maintenance_work_mem был бы на порядок больше чем 12GB, потому что каждый отдельно взятый posting list не превышал бы INT_MAX = 12GB;
4. Почему (1) работает? Потому что CREATE INDEX в таком случае сделает построение за несколько циклов "накопить в памяти — сбросить на диск", и в каждом цикле posting list count будет гарантированно влезать в INT_MAX;
5. Почему PostgreSQL при старте не ограничивает maintenance_work_mem <= 12GB довольно просто: потому что данный резерв используется не только для построения индексов GIN, но и для всяких VACUUM и т.д., где больший объем памяти мог бы пригодиться.

Теперь касательно моих наблюдений, не входящих в сессию общения с Сигаевым:
1. Как ни странно, при maintenance_work_mem = 12GB GIN индекс строится на 20-25% быстрее. Но это только в моём конкретном случае, впрочем;
3. Никакой крупной "утечки" не было, индекс в моём случае действительно целиком влезал в RAM (такое поведение также подтвердил Федор);
2. А, ну и всё. Ждем parallel workers для построения индексов не только типа b-tree, а то на одном ядре тяжко.

#backend #devops #pgsql #programming #russian

0

22.02.2020

1 ответов

31 просмотр

Yaroslav Schekin · Accepted Answer

Т.е. код мы с Вами прочитали правильно, в общем-то (п.1 — п.3 видно прямо в том коде; про п.4 я просто догадывался, код не смотрел; 5 — логично). Но, вообще, было бы неплохо, если бы это ограничение сняли, как видно. ;) > . Никакой крупной "утечки" не было, индекс в моём случае действительно целиком влезал в RAM А, т.е. posting lists строятся не по одному, получается? Если так — ещё лучше (на эту тему код я вообще не читал). Спасибо за информацию!

172 похожих чатов

Ярослав, добрый вечер! Удалось пообщаться с Федором Сигаевым (напомню, что

1 ответов

Похожие вопросы