altair86, почему tu то?) Ещё раз, ключевое место в этом запросе, та информация которая помогает вам понять что запрос можно оптимизировать выбрав по индексу несколько tid'ов из tu - это то, что выборка по t.OrderStatusID оставляет небольшое число различных tid. PostgreSQL получит эту информацию после analyze таблицы t :). Но вполне возможно что есть что-то ещё, что я упускаю, и analyze будет недостаточно.
Построчный ввод занимает много времени. И можно чуть-чуть времени выиграть если переписывать родителя для каждой ноды в find_set, а не через одну. У меня последние тесты прошли на 2.1, 4.5 и 4.9 сек.
Немного смешно слышать - это про "базовый функционал одинаково". Так и gitweb можно туда же записать, и голый сервер с ssh. А в чем "ненормальность" пайплайнов Gitlab CI?
break поставь и не будет этих 20 лишних строк
btw, я так и не понял почему while а не что-то вроде snmpwalk | ( head -n 50 | cat; killall snmpwalk )… ну и killall тут тоже не очень красиво…
Ну на ARP запросы то он в любом случае должен отвечать, если активно вредит… Ну и на последок ещё один действенный способ — посмотрите по логам прокси-сервера на какую страничку вконтакта он больше всего ходит.
