Rsa97

В Asterisk такое можно сделать аж двумя способами (как минимум):
1. dialplan
а. Можно через curl послать запрос:
https://docs.asterisk.org/Asterisk_21_Documentatio...

б. Можно заранее сопоставление входящего номера - внутреннего запихнуть в базу и потом через DB() вытаскивать

в. Обратиться к произвольной базе через ODBC()

2. рядом поставить сервер, который будет подключаться по AMI и посылать Redirect команду при поступлении звонка (какое там событие - не помню)

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

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

Никак

обычной встройки на материнке в 99% случаев будет достаточно

Rsa97 правильно написал про геометрический смысл. Но есть более быстрое решение за O(n log n), использующее метод заметающей прямой.

Пересеките все прямоугольники с тем, который надо покрыть, отрезав от них торчащую наружу часть.

Если числа в задаче большие или нецелые, то сначала через бинпоиск или хешмап замените все координаты по X и по Y на их порядковый номер в отсортированном массиве (отдельно по каждой оси). Эта операция называется "сжатие координат". Теперь у вас все координаты целые числа от 0 до 2*n.

Потом примените алгоритм "заметающей прямой". Представьте, что вертикальная линия двигается слева-направо и "заметает" картинку. Вам надо отслеживать, какие прямоугольники ее пересекают в каждый момент времени и проверить, что вся прямая покрыта в каждый момент.

Для этого каждый прямоугольник (X1, Y1, X2, Y2) создаст 2 события "открылся отрезок с Y1 до Y2 во время X1" и "закрылся отрезок с Y1 до Y2 во время X2". Эти все события вы сортируете по X и в таком порядке обрабатываете.

Для отслеживания состояния прямой используйте дерево отрезков на минимум с отложенной суммой. Эта структура данных потребует массив на примерно 4n элементов для дерева с 2n листами. Каждая вершина будет хранить минимум на соответсвующем ей отрезке. При открытии прямоугольника вы должны добавить +1 на его отрезок. При закрытии - вычесть 1. Сначала открывайте прямоугольники, если время у событий одинаковое. Учитывайте это при сортировке. Так касающиеся по вертикали прямоугольники не создадут пустых мест.
Если после обработки какого-либо события вы получили минимум в дереве отрезков 0 и следующее событие имеет большую координату по X - то какая-то часть оказалась не покрыта. Еще есть случай, если первое событие не X1=левая граница покрываемого прямоугольника, или последнее событие - не X2=правая граница всего прямоугольника. Тут тоже покрытия нет.

Еще, аккуратно с целыми числами, чтобы если у вас 2 прямоугольника касаются горизонтальными сторонами - там пустое место не подсчиталось. Например, каждый лист дерева отвечает за единичный отрезок координат. Тогда изменяйте в дереве всегда отрезок от Y1 до Y2-1 для события с координатам Y1..Y2.

Можно так:

-- Создаём табличку
CREATE TABLE IF NOT EXISTS employee (id int PRIMARY KEY, name text not null, salary int not null);

-- Для примера две записи
insert into employee (id, name, salary) values (1, 'Иван', 10000);
insert into employee (id, name, salary) values (2, 'Пётр', 20000);

-- Обновляем запись
UPDATE employee set salary = 15000 WHERE id = 1;

-- Обновляем запись с нашим условием - если переданное значение больше того что уже хранится, то вставляем его, иначе оставляем как было
-- "переданное значение" тут =5000
UPDATE employee SET salary = max(salary, 5000) WHERE id = 1;

-- Ну и выбираем результат
SELECT * from employee;

В выводе будет:

1 Иван 15000
2 Пётр 20000

Ну и ещё есть выражение CASE и функция IIF(condition, on_true, on_false).

Отложите питон в сторонку, откройте книжку по дискретной математике, на разделе теории графов. Изучите алгоритм Дейкстры, посидите пару часов с карандашом и листочком, промоделируйте на бумаге, как он работает.

Удивительно. Судя по истории вопросов, человек вроде бы занимается программированием почти 10 лет, с 2016 года.
Но до сих пор рассуждает, как Чебурашка:
- Гена, давай я понесу чемоданы, а ты понесёшь меня!

можно ли как-то эту нагрузку снизить

Можно. Для этого надо разместить эти строки в базе данных.

Сделать нормализацию структуры базы.
Перенести JSON в таблицу user_phone.
Поля:
phone_id, -- первичный ключ телефона
user_id, -- внешний ключ, кому относится телефон
phone, -- телефон
phone_comment, -- комментарий к телефону
-- еще поля по вкусу, но иногда выручающие
is_main, -- основной не основной/порядок приоритета
add_date -- дата внесения телефона
И в запросах уже нормально джойнить и лайкать эту таблицу.
PS:
В качестве временного костыля (ни в коем случае не оставлять на постоянной основе!):

SELECT Users.*,
       ph.value->>'phone' as phone
FROM Users, json_array_elements(Users.phones) as ph
where ph.value->>'phone'   like '7%3';

Точного метода без перебора нет

Не понятно какая связь между ядрами и портами? компьютер с один ядром может слушать N портов, компьютер с N ядрами так же может слушать N портов. Эффективность вообще тут боком, а для ее измерения минимум нужно установить критерий по которому ее фиксируем.
ЗЫ взять тот же event loop в питоновском asyncio (на самом деле в остальных языках тоже дофига подобного), он без проблем может держать и обрабатывать 10к коннектов на одному порту, на одном процессе (считай ядре), но если кривыми руками там вызвать тяжелый синхронный код, то всё.

Какие могут быть варианты решения проблемы?

Не выдумывать на ровном месте проблемы. Всё на стороне клиента можно отредактировать и подменить.