В Postgres база раздувается как на дрожжах

На каждую операцию update тоже создается копия, индексы также занимают место. Зачем многократная перезапись? Автовакуум отключен, небось? Размер страницы какой? Транзакция закрывается после работы импорта?

После вставки один раз каждый объект перезаписывается. Так логика сильно упрощается, т.к. только после вставки объекта в дерево можно на полную мощь пользоваться функционалом, предоставляемым деревом. Т.е. после вставки в дерево (insert), производятся некоторые вычисления и апдейт.

Всё что касается атовакуума осталось в настройках по дефолту (postgres версии 9.4), я их не трогал. Хотя в процессе импорта (он долго идет) вручную в консоли postgres VACUUM запускал несколько раз - база продолжала расти, только VACUUM (FULL) помогал.

Средний размер - несколько килобайт или десятков килобайт, иногда до 1-8 мегабайт текста.

Надеюсь :) В джанго нет команды явного закрытия транзакции, в документации написано, что она автоматически закрывается по окончании атомарного блока кода.

---------- Добавлено 29.07.2017 в 14:58 ----------

И еще пара вопросов:

1) Я заметил, скорость импорта заметно падает после середины импорта. Может это быть связано с разрастанием базы? Или в сторону индексов смотреть?

2) Vacuum (FULL) можно запускать при импорте? Кроме временной задержки (из-за полной блокировки) ничего деструктивного для импорта не должно произойти?

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

Можно запускать, будет блокировка базы правда на время вакуума.

А вы пробовали в этой вашей джанге @transaction.atomic использовать, чтобы вся процедура импорта была атомарной. Или наоборот, не использовать :)

Пробовал. Но сильной разницы в разрастании базы не увидел (хотя наверно она есть). В один поток я использовал @transaction.atomic на всю ф-цию импорта документа. Но в один поток импорт очень долго идет, хотя надежно. Пробовал в шесть потоков (на шестиядерном интеле) запускать, правда пришлось использовать табличные блокировки, а от транзакций отказался, да и в целостности дерева не уверен после такого импорта, хотя в разы быстрее конечно.

В этой библиотеке 3 разных вида деревьев. Какой именно используется ? Nested ?

Есть. Можно вообще перед импортом открыть транзакцию, а в конце ее закрыть.

Вообще ситуация странная, сколько использую дефолтно настроенный постгрес - подобного не видел.

Как вариант включить логи и посмотреть что именно происходит с базой. Индексы ключей ну никак не могут столько занимать.

Кстати зачем запустать VACUUM ? Он же сам должен запускаться с установленной периодичностью.

Stek, я вроде нашел вероятную причину. Знал ведь о ней, но подзабыл. Я импорт делаю через manage.py, так вот там в нем оказалась прописана ссыль на конфиг "dev", в котором DEBUG=True, а в этом случае ведется отладочный лог SQL-запросов, что при большом объеме запросов приводит к утечкам памяти и прочим неприятностям. В общем я грешу на это. С выключенной отладкой база разрастается до 40Гб примерно. Но это еще хоть объяснимо, что 10Гб (вернее 20Гб - там тест дублируется) разрастаются до 40Гб. А то что VACUUM (FULL) сокращает базу до 2.7Гб, я думаю из за того, что он данные вроде как в бинарном виде хранит, т.е. похоже сжимает прилично.

Ну и как отладка может повлиять на размер базы данных? Эта ваша джага-джанга в базу данных логи пишет что-ли? %)

Как сконфигурируешь, так и будет , хоть в базу хоть на почту .

Тут не будет ответа, пока не включить логгирование запросов в базе или в той же джанге (в файл). Потом сделать импорт скажем 10 записей и глазками смотреть, что происходит.