Наличие индексов - это основной огранчитель скороти вставки данных в

БД. Особенно если они не влезают в память и ключи вставляются в случайном порядке. Тогда практически каждая вставка требует загрузки страниц индекса с диска в память (по крайне мере листьевой странички, максимально - высота дерева: 3-5 страниц). HDD способен делать 100 случайных read-ов в секунду. Соотвественно при наличии нескольких индексов получаем потрясающую производительность - 10 вставок в секунду! Это, конечно, клинический случай и овременные SSD гораздо толерантней относятся к случайным чтениям... Но проблема остаётся...

С другой стороны большиство запросов без индексов за приемлемое время не выполнишь...

Что делать? Сразу скажу, что идеального решения я не знаю и вряд ли оно есть.

Кто-то пытаетя извращаться - грузить данные в таблицу без индексов, потом в бэкграунде строить для неё matview и длля неё определять индексы.

Можно попробовть исспользовать partial index-ы (индекса по условию). Я пытался протолкнуть в community патч, позволяющий менять уствие для partial index-ов. Тогда можно с максимальной скроростью залить данные в область не покрываемую partial index-ом, а потом "ночью" натянуть индекс на на оставшуюся часть. Патч не приняли. Но всё равно можно пытаться создавать partial индексы, например за день.

Ну и более-менее универсальное решение, но с ограничениями - это партишининг. Разбиваем таблицу на части. За счёт этого добиваемся того, что размер индексов становится маленьким. Но если нужен глобальный индекс, это не работает.

Подход с удалением и созданием индексов заново тоже при определённых условия может работать. При создании B-Tree индекса потгрес предварительно сортирует записи. Даже если индекс не влезает в память. merge sort - требует гораздо меньше операция диском. чем при случайной вставки ключей. Правда в этом случае на время создания индекса не получится гонять запросы... Ну или иметь две копии таблицы и копировать данные между ними. В общем этот подход работает только если есть offline период, когда пользователи с базой не работают и можно заняться перестройкой.

Константин, вот нафига ж ты такое пишешь... 80% людей, встретив такой тектс, ДАЛЬШЕ ПЕРВОГО АБЗАЦА НЕ ПРОДВИНУТСЯ.

если взять другой буффер менеджер и немного другой индекс то было бы лучше но это уже не про постгрес.

А где полайкать патч?

> Наличие индексов - это основной огранчитель скороти вставки данных в БД. Особенно если они не влезают в память и ключи вставляются в случайном порядке. Тогда практически каждая вставка требует загрузки страниц индекса с диска в память (по крайне мере листьевой странички, максимально - высота дерева: 3-5 страниц). Индексы на LSM-деревьях решают проблемы медленной вставки?

А можно про "Ну и более-менее универсальное решение, но с ограничениями - это партишининг. Разбиваем таблицу на части. За счёт этого добиваемся того, что размер индексов становится маленьким." поподробнее? С виду, это работает в исчезающе малом количестве случаев (по сравнению с индексами на непартиционированной таблице)... Есть какие-нибудь адекватные benchmarks?