Мы, как разработчики, должны четко понимать, что бизнес-логика может вставить в БД. Для нормальной работы достаточно не вставлять то, что не может вставить бизнес-логика.

Т.к. любой юнит-тест это обычная хранимая процедура, то для sql-разрабочика порога нет.

Без проблем. Есть плагин для Jenkins. Сама аббревиатура TAP это один из тех модных форматов типа yaml и xml. Небольшой парсер и можно встраивать буквально куда угодно.

Вот версия со всеми доработками. Также имеется pull-request.

Надо сказать, что любой sql-разработчик уже пишет все, что нужно юнит-тесту. Осталось приучить его оформлять свою работу в виде артефакта юнит-тест. Два три подхода к этому упражнению и привычка будет сформирована.

Каждый тест должен проверять не большую часть бизнес-логики, поэтому слишком большого набора тестовых данных быть не должно.

Если все тесты были написаны с идеей о том, что каждый юнит-тест проверяет небольшую часть бизнес-логики, то запуск всего набора не будет проблемой никогда.

Это дело вкуса и для данной задачи подошли бы оба, в других случаях perf предлагает больше гибкости в анализе собранной информации.

Так как исходный код утилиты от меня закрыт, то это был единственный способ повышения производительности. И, конечно, этот трюк работает в тех случаях, когда у вас мощное железо как на стороне Oracle, так и на стороне PostgreSQL. В других случаях может не сработать.

Мы изначально выключили autovacuum, так как выяснили на этапе миграции данных (предыдущем этапе), что он довольно сильно негативно влияет на скорость переноса данных.
Далее мы его уже не включали при отладке следующих этапов. Мы считаем что наличие autovacuum внесёт слишком большую долю «энтропии» в процесс, а нам нужен отлаженный и надёжный процесс.