А есть бест практис для CONCURRENTLY индексов? для каких данных

Question

pgsql – PostgreSQL

Martin Piu

А есть бест практис для CONCURRENTLY индексов? для каких данных

лучше всего их юзать?

#backend #devops #pgsql #programming #russian

0

23.01.2022

13 ответов

17 просмотров

Alex

Могу привести пример с текущей работы - есть очень большая таблица (> 100М записей), которая является очень часто используемой. Обычная комманда create index заблокировала бы таблицу почти на час чтобы построить индекс. Очевидно что это не приемлемо. Для таких случаев и нужен concurently - чтобы не блокировать работу с таблицей.

0

23.01.2022

punkin ☘

Alex
Могу привести пример с текущей работы - есть очень...

А индекс строиться только 1 раз ? Я прочитал что CONCURRENTLY не блокирует операции вставки/обновления , я понял это так : если в таблицу часто происходят вставки нужен CONCURRENTLY т.к индекс будет пересоздаваться при каждом обновлении таблицы правильно?

0

23.01.2022

Alex

punkin ☘
А индекс строиться только 1 раз ? Я прочитал что C...

Он не будет пересоздаваться при каждой вставке в таблицу. Индекс это структура данных. Если мы говорим о b-tree, то по-идее дерево должно просто перебалансироваться.

0

23.01.2022

Максим Мартынов

punkin ☘
А индекс строиться только 1 раз ? Я прочитал что C...

Сам индекс создаётся точно такой же. Просто происходит это без блокировки таблицы

0

23.01.2022

ks

Alex
Он не будет пересоздаваться при каждой вставке в т...

должно или перебалансируется? Раньше в 9 версии было, что индекс бтрии именно просто добавлялся и сам по себе никогда не балансировался. Поэтому его надо было создавать новый паралельно и удалять старый. Сейчас это не так?

0

23.01.2022

punkin ☘

Максим Мартынов
Сам индекс создаётся точно такой же. Просто происх...

Ааа, я вроде-бы понял если я прямо сейчас хочу создать индекс, но на данный момент происходят операции вставка/обновления, то нужен CONCURRENTLTY т.к иденкс не будет создан до тех пор пока не завершаться все эти транзакции. Если же базой никто не пользоваться я могу спокойно CREATE INDEX без concurently

0

23.01.2022

Alex

ks
должно или перебалансируется? Раньше в 9 версии бы...

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

0

23.01.2022

ks

Alex
Скажем так, это моя догадка о том как работают инд...

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

0

23.01.2022

Максим Мартынов

punkin ☘
Ааа, я вроде-бы понял если я прямо сейчас хочу соз...

https://habr.com/ru/company/postgrespro/blog/326096

0

23.01.2022

Ilya Anfimov

ks
должно или перебалансируется? Раньше в 9 версии бы...

Это представление в корне неверное ни для 9 версии, ни для какой.

0

23.01.2022

ks

Ilya Anfimov
Это представление в корне неверное ни для 9 версии...

как правильно, напишите, пожалуйста?

0

23.01.2022

Ilya Anfimov

ks
тогда рискну погадать, что ваша догадка не верная....

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

0

23.01.2022

Аноним · Accepted Answer

Аноним

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

0

23.01.2022

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

А есть бест практис для CONCURRENTLY индексов? для каких данных

13 ответов

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