три раза ты написал в нем
IN (108,250,226,221,471,413,493,346,421,160,341,157,271,460,205,55,30,14,428,10,325,331,226,239,151,445,354,119,243,348,101,109,471,97,313,269,413,287,358,462,210,182,358,107,180,17,156,261,493,496,481,178,78,439,309,223,424,408,302,297,29,329,348,375,167,92,231,193,159,293,137,341,136,397,331,164,431,479,67,36,69,431,186,420,88,185,6,416,158,339,288,330,363,163,489,490,32,423,389,319,483,251,159,443,168,157,273,440,366,163,134,160,374,230,427)

Не особо понимаю как связать с юзером, у которого ID == 1

ты не понял. зачем писать 3 раза одно и тоже?

А как можно написать по другому? Мне нужны только те офферы, у которых есть хоть один департамент, который так же фигурирует у юзера в его m2m.

"чтобы Вам помочь - надо погрузиться в предметную область, раскурить логику этого запроса, так ещё и оптимизировать)" читайте выше, код выглядит как говно

Ладно, anyway спасибо)

Вообще, если речь о том, что в запрос каждый источник (локальная таблица, внешнее API) вместе поставляет по паре тысяч результатов и этих источников ну штук 5 -- то на этом можно в принцыпе забить на всякие индэксы и прочее. Ну, обычно. В смысле -- если всё ,как обычно, ограничивается десятками-сотнями запросов в секунду, и всё упирается в типичные скорости round-trip для web -- то есть сотни миллисекунд и первые секунды.
Тогда эти 10 тысяч отсортируются в памяти, очень быстро, и затраты на попытки как-то их сортировать предварительно по индэксам выглядят преждевременной оптимизацыей, разменивающей дешёвое жэлезо на дорогое время программиста.

Вообще, в моем случае в локальной таблице около 1к записей, а в API 2.7к, но надо учитывать, что завтра будет в десятки-сотни раз больше, поэтому это и важно. И нужно эти 2 ресурса собрать и запагинатить нормально, вместо того, чтобы доставать все сразу. Мало того, их надо сложить в шахматном порядке по какому-то критерию

всем привет. куда лучше тут копать? база - pg

1. есть множество юзеров, которые могут входить в одну или несколько групп
2. есть множество записей в таблице базы, которые могут быть видны одной или нескольким группам
3. нужно выбрать все записи для какого-то одного конкретного пользователя, видимость которых разрешена в этих группах

пока что таблицы групп не существует, нужно дописывать.

вопрос. как подобное лучше выполнить, цель: максимальная скорость выборок на запросе списка записей

Как вариант — через view, в котором будет прописана в where область видимости таблицы в зависимости от нужных вам условий, а затем — grant select на это вью, а не на таблицу

Если речь про кейс, где, например, роли А видны записи с id 1..10, роли Б — с id 11..20 и т.д.

Уточняю. Пользователи реализованы таблицей, то есть это не фича базы
Сейчас в базе есть две полностью независимых таблицы: пользователи и некоторые записи. Нужно придумать третью, группы, которые связали бы юзеров с записями и запрос, который выбирал бы для конкретного юзера записи, которые ему видны
Имеющиеся таблицы можно менять как угодно

подскажите пожалуйста как получить ссылку на БД ?

Напишите вашу проблему, без xy problem

Backseat driving - о случаях, когда человек даёт ненужные советы и пытается помочь во вред

я написал

в монго например можно получить ссылку на БД, как это сделать в постгресе?

Кажется, ничего с названием "ссылка на БД" в постгресе нет.

https://stackoverflow.com/questions/3582552/what-is-the-format-for-the-postgresql-connection-string-url
видимо URL имеется в виду

но вопрос "как получить?" ставит в тупик
как? написать ))