1) у тебя получается 2 сетевых взаимодействия вместо одного. причем в первый хоп ты можешь получить огромный список id, который
- весь надо достать с диска в память базы
- упаковать и отправить по сети
- протащить по сети и положить в оперативку приложения
- сформировать большой запрос
- отправить его по сети в базу
- протащить по сети, распаковать в оперативу базы
- распарсить запрос
- выбрать по айдишникам все записи из второй таблицы
2) конкретно в посгресе, если ты запихаешь в IN больше 100 значений, индексы применяться для этой операции не будут
Вот мне кажется, что это немного ответ из XX века. Если серверы приложения и данных стоят в одной или соседних стойках, соединены гигабитной медью и TCP-коннект уже установлен, то все сетевые танцы занимают единицы миллисекунд, причем нижние единицы, типа 2-3. Если у сервера много памяти (по стандартам XXI века - десятки гигабайт), то все индексы скорее всего закэшированы там. Если при этом сторадж у сервера БД тоже современный NVMe, то даже достаточно суровые дисковые операции уложатся в нижние десятки миллисекунд. То есть мы получаем round trip одного запроса при хорошем раскладе в 5-10 миллисекунд, при плохом - 20-30.
