Вы затронули сеть, пул соединений и задержки, но не упомянули сравнение планов запросов. Можете рассказать, как изменение плана запроса может влиять на p95?

Неудачный план может читать намного больше строк, выбрать дорогой JOIN или выполнять сортировку на диске. При этом среднее время и CPU всей БД не всегда показывают ухудшение хвоста p95.

Сравнивайте планы для одинаковых запросов и характерных параметров: оценки количества строк, фактические loops, объём буферов и временные файлы. Причиной смены могут быть статистика, распределение значений, новые индексы или generic plan подготовленного запроса. Важно отдельно воспроизвести медленные значения параметров, а не только удобный пример. Смена плана — гипотеза, которую подтверждают измерением, не повод безусловно запрещать sequential scan.