Артем Черепахин

Начни с https://postgrespro.ru/education/courses

Сделайте смещение на константу= 9223372036854775807, т.е. от значение отнимите. Затем чтобы получить значение прибавьте эту же константу.
Если они нужны только для просмотра, храните в тексте.

Все зависит от установите ли вы при установке крыж - "Add Path". При установки это крыжа по-умолчанию будет использоваться последний установленный.
В любом случае можно конкретную версию указывать при запуске- С:\\python37\python.exe c:\\projects\scripts.py
Пути поменять на свои: С:\\python37\python.exe - путь до конкретной версии, c:\\projects\scripts.py- сам скрипт.

В принципе GROUP BY в запросе будет сканировать всю таблицу в 90%. Можно конечно попробовать поиграться с составными индексами на таблицу логов. Запрос переписывать...
Самый простой способ, на мой взгляд, в исполнении и работает ad-hoc:
Добавьте поле в таблицу devices(назовем его lastidevent ) и сделайте триггер на вставку в таблицу eventlog, который будет обновлять поле lastidevent на вставляемый id_event в таблице devices. Затем в запросе соединять с таблицей логов по полю lastidevent.
Т.к. таблица devices не нагружена, то конкуренция будет минимальна. Правда, придется считаться с возросшими расходами на вставку логов.

Средствами реляционной БД и если не критична скорость вставки, то можно попробовать реорганизовать таблицу со строками
{"1": [1,5,11,15,22,34...], "5": [55,44,22,67]}
к виду {1:["1"], 5:["1"], ...., 22:["1", "5"]}, т.е. теперь первым стоит значение для проверки, потом массив ключей- поменять местами ключи со значениями.
Делаете 1 индекс.
Жрать ресурсов будем меньше+ скорость поиска, усложняется доступ к бывшим ключам вхождения("1", "2",...).
Можно попробовать создать 2 таблицы: первая просто число, которое нужно искать(скорость поиска О(1)+высота дерева в индексе), а вторую с ключами вхождения и внешний ключ к первой.

Если я правильно понял задачу, то есть в SQL оконные функции LAG и LEAD, погуглите их.

Первое значение в raise_application_error- должен быть из диапазона пользовательских ошибок:
PROCEDURE null_args_testing(arg IN VARCHAR2) IS
BEGIN
if arg is null then
raise_application_error(-20101, 'Значение не может быть NULL');
end if;

NULL;
END;
Еще можно вот так, если нужна более сложная логика:
PROCEDURE null_args_testing(arg IN VARCHAR2) IS
p_is_null exception;
BEGIN
if arg is null then
raise p_is_null;
end if;

exception
when p_is_null then
/*логика обработки*/
raise;/*процедура завершается*/
END;

Если под "каждый запрос начинался с того момента когда был запущен предыдущий" подразумевается, что необходимы данные на конкретный период времени, т.е. не учитывая изменения в таблице с указанного времени, то можно воспользоваться ретроспективной областью памяти(https://docs.oracle.com/cd/B14117_01/appdev.101/b1... Пример:
SELECT * FROM employee AS OF TIMESTAMP
TO_TIMESTAMP('2003-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')
WHERE name = 'JOHN';
Т.е. запрос к таблице -SELECT * FROM employee
передаем метку scn - AS OF TIMESTAMP TO_TIMESTAMP('2003-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')
условие- WHERE name = 'JOHN';
Перед выполнением первого запроса сохраняем метку времени и вставляем таким образом во все запросы.
Если разница в долях секундах приемлема, то можно создать курсоры подряд ко всем интересующим таблицам
т.е.
declare
х1 refcursor;
х2 refcursor;
...
begin
open х1 for select * from t1;
open х2 for select * from t2;
....
end;
Затем при работе курсоры будут выводить данные с разницей в доли секунд.