Dannerty

Если не ошибаюсь:
MS SQl не требует пользовательских CALов если лицензированы ядра (но можно купить версию не на ядра, а на MS SQL сервер+CAL'ы). Для RDP отдельные CAL'ы, но если у Вас Windows Server - разрешено два одновременных удаленных подключения с целью администрирования сервера, без покупки дополнительных CAL'ов и без роли Remote Desktop Services.

Наиболее близкий пример - Пример №9
https://www.zabbix.com/documentation/3.2/ru/manual...
Оттолкнитесь от него и опишите выражением триггера свой кейс, указав и дату, и время

Да я тоже с этим сталкивался.
Не могу сейчас точно вспомнить, что получилось, но можно попробовать:
Requires=graphical.target
тогда его будет вырубать когда вырубают graphical.target.
Или еще к чему более разумному прицепиться.
Скажем к network.target.
Без сети то zabbix точно не нужен.

Нужен explain (analyze,buffers), сильно желательно с track_io_timing = on в конфиге.

параметр work_mem на данный запрос не может оказывать почти никакого влияния

Оказывает. Если планировщик решит, что work_mem не хватает - не будет hash join. Для сортировки 27кб, очевидно, без разницы.

Впрочем, зачем вам вообще join подзапроса где одна только группировка подзапроса занимает половину времени ответа? Вам простой exists нужен.

SELECT "t1".* FROM table_1 as t1
where exists (select 1 from table_2 as t2 WHERE t1.primarykey=t2.session)
ORDER BY "starttime" DESC LIMIT 20;

А дальше know your data. Если по starttime DESC быстро находятся нужные exists - будет хорошо. Если exists мало - стоит подумать, а не денормализовать ли этот признак в table_1 с триггером для консистентности в table_2 и частичным индексом по starttime where t2_exists.

Поля session и primarykey в формате uuid

Не очень хорошая идея. Оно и сильно медленнее при сравнении относительно bigint (особенно если речь о varchar, а не uuid типе данных) и из-за случайного распределения несколько сбивает с толку статистику планировщика.

Вообще не с потгресом работаю, но...
Смущает блок (select session from table_2 group by session)
Получается, Вы берёте (и сортируете!) все номера сессий из таблицы 2, в которой 6 421 212 строк, только ради того, чтобы проджоинить с таблицей 1, у которой 4 723 505 строк. Итого сортируем 6 миллионов строк, чтобы отфильтровать 4 миллиона.

Может быть имеет смысл вывернуть запрос наизнанку:

SELECT * FROM table_1 
WHERE primarykey=(SELECT session FROM table_2 WHERE table_2.session=table_1.primarykey LIMIT 1) 
ORDER BY "starttime" DESC LIMIT 20;

В итоге большую сортировку сессий меняем на штучные проверки (по индексу!) для выбираемых строк в соответствии с датой. Еще можно порезать диапазон дат, чтобы работать с недельным/месячным набором, а не всей историей.