Gregory's Server
Задумался, а как мне это всё в работе поможет и чот хз. Пока самое эффективное, что я делал, было избавление от insert ignore on conflict + update (разбивка по группам, почти равномерная по модулю от autoincrement integer id) всего что не заигнорилось, заменив это на вставку чанками по 1000 строк с чередованием этих групп и последующим выравниванием недавно вставленного с помощью хитрожопой математики. Благодаря этому получилось для 90% вставляемых строк создать всего одну версию строки, изначально, ещё при вставке выбрав им нужную группу. Дисковое I/O в итоге сократилось на 40% где-то, но помимо этого оно ещё и сгладилось (благодаря вставке чанками), а лаг репликации сократился без лишних апдейтов под той же транзакцией.
Всё это было бы не нужно, если бы все-все-все команды коллег взялись и организовали унифицированный экспорт данных с временными метками изменений, а все-все-все пользователи нашего сервиса писали бы SQL-запросы с учётом этих меток (CDC), чтобы не тянуть каждый раз много данных, и ещё все старые запущенные кампании поправили под это требование. Ух зажили бы.
TIL что NOT EXISTS / EXISTS ... вырождаются в anti/semi-join, типа LEFT JOIN ... WHERE key IS NULL и при наличии индекса на key, всё выглядит не так уж страшно.
А ещё задумался, что при массовой вставке строк с использованием моделей #ORM явно стоит перепроверить, какой #clocksource стоит в системе (и махнуть его на tsm, если не нужна сверхточность). Беда только в том, что в случае managed postgres, прямого доступа к БД нет и проверить это несколько сложновато (хотя, по-любому в psql есть встроенный remote cat и доступ к файловой системе), а потом ещё и с командой, которая постгрес крутит этот вопрос обкашливать, потом выяснится, что clocksource глобальный на всех, что кому-то эта точность нужна и вообще чего суету навёл, нормально ж и стабильно живём.
Кажется, проще захачить нашу базовую модель, чтобы при вставке строк created_at можно было переопределить и не заполнять автоматом, а вместо этого вычислить его один раз на стороне приложеньки и забить хуй на пятиминутную погрешеность при большой транзакции.
TIL что NOT EXISTS / EXISTS ... вырождаются в anti/semi-join, типа LEFT JOIN ... WHERE key IS NULL и при наличии индекса на key, всё выглядит не так уж страшно.
А ещё задумался, что при массовой вставке строк с использованием моделей #ORM явно стоит перепроверить, какой #clocksource стоит в системе (и махнуть его на tsm, если не нужна сверхточность). Беда только в том, что в случае managed postgres, прямого доступа к БД нет и проверить это несколько сложновато (хотя, по-любому в psql есть встроенный...