Обновить
3
0
Дмитрий Фатов@FatOFF

Пользователь

Отправить сообщение

Спасибо за комментарий. Согласен, ждать восстановления индекса в текущей реализации для данного бизнес процесса не имеет смысла. В этой статье я хотел показать замеры полного процесса "от звонка до звонка". Ну и в целом не рекомендую использовать данный подход, потому что он может сильно повлиять на производительность системы. Как в момент вставок (пользователи работают без индексов), так и в момент восстановления индексов. Все эти процессы так или иначе будут грузить и без того часто сильно загруженную БД.

Спасибо! Рад что понравилось :)

Хороший подход. Однако когда речь идет про финансы, он может не устраивать бизнес.

Ну лучше точно не будет, т.к. PostgreSQL будет выполнять дополнительные действия. Данные модификатор не про скорость и распараллеливание процесса создания индекса, как можно подумать, а про то, что PG не накладывает блокировки на запись, и индекс создается параллельно другим процессам вставки (обновления). Вот тут подробнее описано https://postgrespro.ru/docs/postgresql/current/sql-createindex#SQL-CREATEINDEX-CONCURRENTLY

Нет, не использовался.

Не совсем так. Этим процессом мы управляем вручную. Т.е. сначала складываем в буфер то что мы хотим сохранить методом copy, затем отправляем в БД. На моем примере я делал вставки батчами по 5_000 записей.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность

Специализация

Бэкенд разработчик
Ведущий
SQL
PostgreSQL
Java
Java Spring Framework
Spring Boot
JDBC
Hibernate
Базы данных
Linux
Английский язык