только на время загрузки?
или на виниле жить со вторичным индексом не получится ?

не помогло, через какое-то время в логе опять
too long WAL write

может влиять то, что первичный индекс составной?

Да

Ну, вторичные индексы сильно всё портят. Можно потюнить, но сложно.

Я предлагал попробовать на время загрузки.

Не должно

А что у вас за диск под базой?

Зеркальный RAID  из 2 SSD

Я бы привлёк кого-то из любителей винила. Типа @kostja_osipov или @akudiyar

понял

Плюсую выключение вторички на время заливки. Однако построение индекса позже тоже займет некоторое время

Спасибо что тэгнули, отпишите пожалуйста проблему в личку

написал в личку

Всем доброго утра. Сорри, если вопрос не в тему. У нас большая система (OLTP), в БД mssql миллионы контактов, у них бонусные карты, покупки/чеки/коммуникации/личный каб. и прочее. Чеки прилетают онлайн неск. десятков в секунду. Логика в этом хозяйстве подчас сложная(вся в БД). Собственно, вопрос в том, разумно ли рассматривать TDG как средство, на котором можно строить подобные системы? У меня опасение, что вообще, Тарантул более заточен под запредельные нагрузки, чем под сложную и развивающуюся логику. А?

всегда интересно было чем руководствовался архитектор выбирая местоположение логики в БД. ведь даже масштабировать сложнее из самых банальных проблем

Отчасти путем наименьшего сопротивления 😊.

вот не согласен, tnt заточен как раз под сложную логику, которую легко реализовать на lua + быстрое, надежное хранилище

На существующих структурах(спейсах, таблицах) изменения/дополнения форматов хранения - операция простая? Скажем, изменить связь типа foreign key, добавить новый триггер и прочие "обычные" изменения?

изменение форматов, индексов, триггеров - операция простая, много проще чем в MySQL и уж точно безопаснее. Я сам много лет писал хранимки на MySQL и знаю какая она тормознутая.

По мне, tnt + clickhouse это лучший вариант для большого класса задач хранения и обработки данных