Я решил проблему по другому, но с предположением, что в течении одного
сеанса закачки данных нет повторяющихся по ключу (условие where в update и select).
Заводим таблицу-кэш - копия первой + 2 поля - id сеанса и наличие.

id сеанса нужно для разделения данных из разных сеансов закачки, если вдруг
в предыдущем произошел сбои и кеш-таблица не очистилась. Теоретически он не нужен.

Процесс:
закачиваем данные в кеш - все инсертами. Таблица небольшая, так что все шустро.
Повторяющихся данных нет - и нам не надо делать проверки. В принципе и индексы можно
делать не unique (да и нужно) - скорость увеличится.
Делаем
update "кеш-таблица" set наличие=True from "наша-таблица" where <измененное под
join таблиц условие поиска> and id-сеанса=<текущее id>
update "наша-таблица" set <присваиваем нужным полям значения из кеша> from "кеш-таблица"
where "кеш-таблица"."наличие"=True and <измененное под join таблиц условие поиска> and
and id-сеанса=<текущее id>
insert into "наша-таблица" select <поля без id сеанса и наличие в нужном порядке>
from "кеш-таблица" where "кеш-таблица"."наличие"=False and id-сеанса=<текущее id>

Таким образом, много INSERT-ов идет на маленькую таблицу (которую можно/нужно часто вакуумить). На таблицу с 2-3 миллионами запись у нас три запроса: один на селект (в апдейте кеша),
один на апдейт и один на инсерт.
Примечание: если сохраняешь план запроса (а это происходит в функции на plpgsql при первом
запуске и на все последующие), то лучше, если в большой таюлице есть данные; планы,
созданные для пустой таблицы быстро становятся не оптимальными.
Как вариант - после первой вставки перекомпилить функцию plpgsql. Команду точно не помню.