во-первых я все еще не понимаю, зачем тебе это делать и почему нельзя передать просто в subquery

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

потому-что есть много rows A, и для каждой есть свой :last_id

много это сколько?

если речь скажем о десятках, максимум сотне, то почему бы не передать их через a.id in (1, 2, 3)

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

в чем вообще верхнеуровневое описание задачи?

Если сейчас запихать это в одну query то вся боль будет решена c хорошим запасом.

on: b.id > a.last_id AND b.id < a.last_id + 3500

вот этот вариан гуд реально, но просто как быть с ямами в индексации я пока не ншел идеи)

AND b.id > (SELECT MAX(id) FROM (SELECT id FROM b WHERE id > a.last_id ORDER BY id ASC LIMIT 3500))?

но выглядит отвратительно

понять бы как это в ecto перевести)

сейчас пойду наверное опять LATERAL пробовать хз

вроде все должно бы было быть просто)

работал бы row_number в where условии и уже после order by, может быть и было бы проще. но sql стандарт к такому строг

или в filter row_number засовывался бы

да и этот способ точно был бы ни разу не производительнее, базе ведь пришлось бы выполнять ровно те же самые операции

если бы и был, он срабатывает раньше order by, поэтому это бесполезно - ты бы выбрал 3500 каких-то строк, подходящих под условие, но хз каких именно

получилось решить, чтобы в subquery передать параметр ее нужно было добавлять как fragment.

но чот медленно оно работает))