Nitro_Junkie<>
идея в том, чтобы в приложении хранить вычисленный список id товаров, например. 150 id много места не займут. при изменении каких-то условий в приложении, запрашивать данные повторно по id.

Запрашивать предварительно загружая 150 id назад во временную таблицу на сервер? Или запрашивать для каждой записи? Я надеюсь вы понимаете, что во втором случае у вас скорость будет в раз 70 меньше?
с этого места пападробней, пжалста.

даже если вы не знаете, что в IN() постгресу можно запихать многия тысячи, чисто по длине оно там мало ограничено (не помню чтобы там был какой-то выделяемый обрезанный ресурс). и то же самое -- можно в =ANY(ARRAY[...,...,,,,,]) . [и никаких времянок]

даже если у вас не уеб-приложение, с гигабитным каналом между уеб--сревером и СУБД--сервером

но если вы не тратите на повторное поднятие соединения
и если, при этом, данные у вас строго холодные
то как вы получите сакраментальное 70 ?
из какой ноздри вытянете ? (препаред стейтменты напра, кстати).

просто интересно , ничего личного.

Nitro_Junkietadminа где же тут сложные клиентские данные, которые приходится во временных таблицах держать?
Достаточно хранить в интерфейсе ID склада и передавать его на сервер. В ответ получать набор данных с товарами и остатками.


Еще раз. У вас есть список товаров отображаемый пользователю (150 штук), он определяется фильтром, порядком и некоторым "окном", до которого пролистал пользователь. Если вы опять будете его перечитывать, СУБД придется опять join'ть с группами товаров, упорядочивать и фильтровать для получения видимого "окна". При этом вам все равно это, по хорошему, надо материализовать во временную таблицу, чтобы ее можно было протолкнуть в подзапросы, если показатели которые надо рассчитать (остатки, цены и т.п.) не материализованны, так как Postgres сам этого делать не умеет, а будет полностью рассчитывать подзапрос для всей базы и только потом Join'ить (даже если вам сильно повезет, и он будет подзапрос выполнять для каждой записи, то скорость будет все равно очень низкой, по сравнению с проталкивание предиката). Если же у вас таблица уже на сервере, первый шаг можно полностью пропустить.
"ты не мудри, ты пальцем покажы"

-- привёл бы неудавшийся запрос, привёл его план. привёл свой обходной путь и выигрыш.
-- с вероятностью в %%95 получил бы свой ушат помоев, но и более подходящий случаю алгоритм. плата невелика, имхо. зато вот оно --всё на руках, и наглядно. а не слова в кучках с места на место гребстить

Nitro_JunkieНо вообще могу дать вам проще пример. Пользователь ввел накладную, и изменил соглашение, надо пересчитать цены по всем строкам для нового соглашения, ваши действия?
а ф чом траблема ?
возьми, да пересчитай

повторяю , однако : "ты не мудри, ты пальцем покажы"

Nitro_Junkie<>

IN и есть по сути временная таблица
нет.
1. хотя бы с т.з. стендбая, на котором запрос с IN вы выполните, а с времянкой -- нет

2. есть смутные сомнения насчет планировщика ПЖ. с IN он на bitmap OR точно полезет (как и с гирляндой OR) -- если это выгодно
то же и с ANY(ARRY[])

а с времянкой -- он обычно даже размер планирует от балды, если аналайз не сказать.
Nitro_Junkie, вам тогда надо постоянно ее везде вставлять, в подзапросы и т.п. (для этого плюс вам как минимум надо постоянно генерировать запросы)с какого перепуга ?
параметр--массив в ANY(ARRY[]) можно передать в prepared statment, он может входить в 100-ни мест вашего стейтмента -- какие проблемы ?
Nitro_Junkie А если у вас еще вторая "таблица" надо, вы CASE'ы писать будете (CASE WHEN a=1 THEN 5, WHEN a=2 THEN 3 ...) и т.п.?-- какая вторая, ты пальцем, или хотя бы клювом покажы, дядя. И как из неё растёт case -- тоже. А то ты себе там что-то умозрительно воображаешь, а признаться битым текстом боисся.

Nitro_JunkieAlexiusпропущено...


1) временная таблица с сотней id вообще не проблема в плане расходов памяти
2) с помощью CTE и VALUES/unnest(array) можно сколько надо "таблиц" насоздавать в запросе.




генерировать запросы с case'ами это безумие (видел умельцев, у которых order by (case ...) на несколько мегабайт получался).

пропущено...


и что? какая тут перекачка то?

То есть вам при КАЖДОМ запросе нужно генерировать соответствующую строку, и пересылать данные на сервер? То есть мне надо допустим одним select'ом считать информацию по всему предприятию, вторым по всем складам. Надо 2 запроса, так как ключи разные, то есть 2 раза полетит эта таблица в шапке запроса. Если же одним запросом, то придется сначала денормализовывать, а потом нормализовать обратно на клиенте. По unnest'у плюс ко всему статистике не будет.

Просто вопрос в том, что временные таблицы в SQL это своего рода локальные переменные в императивных языках. И можно скажем на C++ писать без локальных переменных (только параметры функций использовать), только ЗАЧЕМ?

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

а так -- слова по кругу гребёшь -- и никакого от тебя толку.