не получается, к сожалению. хотя похоже на самый лучший вариант..

Возможно я имена напутал) у меня сработало, в общем запросом берешь максимальный тайминг у конкретных пиров и по нему зпрашиваешь текст

Wal можно выносить точно ибо он пишется строго последовательно, рандомных иопсов не вызывает.
Можно ещё директорию под temporary tables на рамдиск положить (именно так на блочный рамдиск чтобы гарантировать того, что этот объём памяти никуда не используется и не потребуется его внезапно освобождать, скидывая на диск dirty pages. Хотя тут можно спорить долго)

не работает с AND почему то.. но без него все выбирается замечательно..

Почему бы тогда просто максимально не "зажать" temporary files?
Я к тому, что когда этот RAM disk переполнится, результат будет примерно тот же...

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

OR))

or возвращает один обьект

а нужно на каждый пир по одному сообщению

Да погуглите по groupwise maximum (или поищите в истории чата, я тут когда-то около десятка вариантов решения приводил).

Я что-то вопрос не очень понял.
Если что, то я про pgsql_tmp. Можно, конечно, просто выкрутить work_mem настолько, что туда ничего/почти ничего писаться не будет, но тогда мы будем на каждый коннект память выделять, независимо от того нужна она или нет. Сунуть pgsql_tmp на приемлемый по размеру рамдиск (можно ещё и со сжатием) выльется в "чуть медленнее", зато предсказуемо по потреблению памяти, и ,в большинстве случаев, такой подход может немало оперативки сэкономить.
Хотя, как я сказал, холиварно, ситуации бывают разные. Кому-то случается и под 40-50G в этой директории заиметь.

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

Я когда-то предлагал обобщение intarray до anyarray. Отказались, валяется где-то на коммитфестах. Не возражаю, если кто-нибудь поднимет знамя

Благодарю, похоже нашел его: https://commitfest.postgresql.org/4/145/

спасибо большое! оказалось так просто)

Ага, оно

> Если что, то я про pgsql_tmp.

Я тоже. Я имел в виду — ограничить с помощью temp_file_limit, да и всё.

> но тогда мы будем на каждый коннект память выделять, независимо от того нужна она или нет.

Ничего подобного. Work_mem — просто рекомендательное "ограничение", причём на один узел запроса.
Т.е. если запросам в данной сессии столько памяти не нужно — она и не выделяется вообще.
А если требуется больше, т.е. другого выхода нет (я тут как-то приводил примеры) — PostgreSQL попробует выделить сколько нужно, проигнорировав work_mem, кстати.

> Сунуть pgsql_tmp на приемлемый по размеру рамдиск

Мой совет выше — просто чтобы с ram disk не заморачиваться. Хотя таким образом можно ограничить "в общем", минус в непредсказуемых ошибках в запросах в сессиях, когда эта память будет почти исчерпана (т.е. сессии начнут "красть" друг у друга ресурсы). ;)

> такой подход может немало оперативки сэкономить.

Каким образом (по сравнению с тем, чтобы просто ограничить)?

А вообще, по этому вопросу: +1 вот к этому https://t.me/pgsql/230997
Т.е. эти "фокусы" — почти наверняка напрасная трата времени, да и всё.

Спасибо вам большое за статью!