Дмитрий

Function.prototype.defer = function (time) {
   setTimeout(this, time);
};

Конкретно здесь - ссылка на все экземпляры объектов, то есть - на все функции, поскольку все функции - это объекты, наследующие у Function.prototype.

А вообще - это контекст вызова функции. То есть, при прямом вызове метода объекта this укажет на сам объект.

Full scan можно представить себе так:
Мы просматриваем все строки таблицы в том порядке, как они лежат на диске и для каждой строки проверяем условие is_active = 1. Последовательный доступ к диску ( или к памяти, в данном случае не важно ) - это хорошо и быстро.

Доступ с использованием индекса можно представлять себе так:
У нас есть индекс, то есть некоторая дополнительная структура данных, в которой хранится значение проиндексированной колонки и ссылка на саму строку в таблице. В случае сканирования с использованием индекса мы просматриваем строки в том порядке, в котором они лежат в индексе ( то есть с точки зрения доступа к диску - в случайном ). Случайный доступ к диску - это плохо и медленно, мкей?
( это упрощение, но оно нам поможет разобраться )
Вот про это нам и пытался рассказать автор отрывка. К сожалению, формулировка у него неудачная, так как если данное значение индекса возвращает несколько тысяч строк, а таблица большая ( миллионы, например ), то вполне возможно оптимизатор выберет как раз просмотр по индексу, так как выгода от просмотра меньшего числа записей "перевесит" выгоду от последовательного сканирования. Это все зависит от настроек оптимизатора.

Там же есть файл udc_predict.py с примером использования обученной модели для предсказаний

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

Пакеты через шлюз проходят такие цепочки: PREROUTING, FORWARD, POSTROUTING и вам для каждой нужно правило. Еще нужно, что-бы была разрешена пересылка трафика. Нужно не только подменить адрес назначения (DNAT, PREROUTING), но и заменить адрес источника (SNAT, POSTROUTING), что бы Y-хост отвечал X-хосту, а не по маршруту по умолчанию, и еще не забыть про фильтрацию проходящего трафика (FORWARD).

Чтобы все работало, так как описано выше, нужны такие действия:

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p tcp --dport 8888 -j DNAT --to-destination Y.Y.Y.Y:80
iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 80 -j SNAT --to-source X.X.X.X:1024-32000
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED  -m comment --comment "РАЗРЕШЕНО Установленные соединения" -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate NEW -d Y.Y.Y.Y  -m comment --comment "РАЗРЕШЕНО Новое соединение к Y.Y.Y.Y" -j ACCEPT
iptables -P FORWARD DROP

Первая команда разрешает форфард трафика через хост.
Вторая: подмена назначения в PREROUTING, т.е. в точке решения о маршрутизации уже будет принято решения передать пакет дальше в сеть, а не отдавать локальному процессу.
Третья: подмена адреса источника в цепочке POSTROUTING на выходе на адрес X-хоста. И тогда пакет уже будет выглядеть так, будто он с X-хоста был отправлен на 80 порт Y-хоста.
Четвертая: работа со статусами. Пропускает только пакеты уже установленого соединения. А соединение можно установить только в одну сторону (пятая строка) и только до Y-хоста.
Шестая: сбрасывать все пакеты, которые не подпадают под правила цепочки - политика по умолчанию.

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

Еще нужно разобраться с локальным трафиком на 8888 и 80 порты. и трафиком из локальной сети, если это шлюз. Но это уже отдельный вопрос.