вариантов много
1)действительно удалять пачками с задержкой и контролем лага репликации (как раз можно исходя из лага и задержку считать)
2)если удаляется 90% таблицы - то выгоднее что не надо удалять перенести в новую таблицу а старую дропнуть

далее если у вас эта задача регулярная а не разовая то стоит следующие вещи изучить
1)нельзя ли сделать партиционирование таблицы так чтобы просто удалять ненужные партиции целиком (это дешево по wal) вместо удаления данных
2)понять почему репликация отстает
вариантов тут 3ре на самом деле
а)не хватает сети на передачу wal потока (любят некоторые базу на 1gbit сетку поставить и/или c 100+ms сетевой latency между мастером и репликой)
б)не хватает дисков на запись wal на реплике (бывает если дисковая система на реплике перегружена или слабее чем на мастере)
в)не хватает CPU на проигрывание wal на реплике (бывает если CPU по производительности на 1! ядро на реплике заметно слабее чем на мастере)
самое вероятное по моей практике а)
для решения между а-б-в - pg_stat_replication view на мастере используйте там все видно


--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru