Добрый день участникам форума.

Есть нестандартная потребность. Нужно создать таблицу в оперативной памяти.
В postgreSQL есть функция/возможность



Замечательно, но это не решает проблемы. В инструкции раза два встречается упоминание о том, что можно создать раздел в ОПЕРАТИВНОЙ ПАМЯТИ . Я честно искал в интернете, потом отказывался от этой затеи.
Сейчас прижало. Объясню в чем суть проблемы.
Имеется 16 акций, по каждой 10 таблиц. В общем всего 160 таблиц.
Обработка полного набора занимает 0,71 секунд.
На один инструмент/переменную уходит что то типа 0,002 секунды.
Эти результаты хочу объединить в одну таблицу (небольшую).
В итоге таблица с итоговыми результатами будет занята постоянной записью и будут проблемы с считыванием (пока транзакция не завершена).

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

Я понимаю, что вопрос ну уж очень специфичен, но может хоть кто то хоть что то слышал ну или ссылочку скинуть, где это можно узнать глубже.

Сборщик статистики использует временные файлы для передачи собранной информации другим процессам PostgreSQL. Имя каталога, в котором хранятся эти файлы, задаётся параметром
stats_temp_directory, по умолчанию он называется pg_stat_tmp. Для повышения производительности stats_temp_directory


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

Я может не правильно это понимаю, но
фраза " указывать на каталог, расположенный в оперативной памяти,"
звучит как приглашение на создание каталога /табличное пространство в оперативной памяти.

Где то была и прямое упоминание на создание табличного пространства в оперативной памяти.
Сейчас не нашел.

Просьба наставить на путь истинный.
Интернет молчит, может хоть кто то хоть краем уха слышал о данной возможности.

Всем заранее спасибо за любой ответ (по данной тематике).

Павел Лузанов,

Нет, они создаются на обычном жестком диске, но не в оперативке. Проверено, и с ними много проблем. Легче создать уже явную таблицу (ну как по мне).

temp_buffers (integer)
Задаёт максимальное число временных буферов для каждого сеанса, По умолчанию объём временных буферов составляет восемь мегабайт (1024 буфера). Этот параметр можно изменить в
отдельном сеансе, но только до первого обращения к временным таблицам; после этого изменить его значение для текущего сеанса не удастся.
Сеанс выделяет временные буферы по мере необходимости до достижения предела, заданного
параметром temp_buffers. Если сеанс не задействует временные буферы, то для него хранятся
только дескрипторы буферов, которые занимают около 64 байтов (в количестве temp_buffers).
Однако если буфер действительно используется, он будет дополнительно занимать 8192 байта
(или BLCKSZ байтов, в общем случае).

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

Господа, Есть ли у кого еще какие соображения.
.

Maxim Boguk,


Я согласен, что нужно делать unloget table
Но в моем случае - отказ сервера это не критично. Я не брокер и перезагрузка сервера создаст данные заново. Так что в этом плане я никак не привязан в протоколированию изменений в таблицах.

2)использовать unlogged таблицы которые не пишутся в wal log и которые при сбое сервера truncat ятся
и вот тогда скорее всего при достаточном размере shared buffers они будут в оперативке висеть нормально
без извращений с tablespaces на RAM диске

Вот про этот нюанс никак не подумал. Просто оперативки 16 Гб. Таблицы я могу 80% сделать unlogged - никакой потери в случае сбоя не будет (восстановление идет из других таблиц, которые точно должны контролироваться по записям/изменениям).
Но решил сделать, а смысл делать unlogged, путь будут обычными ну и сделал их обычными. При этом размер shared_buffers был и 512 и 1000 и 4000МB, а система показывает, что занято всего 2,6-2,8 Гб оперативки всего на windows. Явно, что оперативна не используется.
Вот поэтому и задумался о tablespaces на RAM диске.

Спасибо ООсс и Maxim Boguk.

Почву, направление нащупал (подсказали) и даже целых два варианта. Вариант с использованием временных таблиц не пугает,
так как размер таблицы итоговой = 16 строк и 60 столбцов. Могу позволить себе даже раз в 5 минут делать truncate этой таблицы. Но да, согласен, если за 1 сек она 160 раз перезаписывается (за 1 минуту = 9600 раз) то в таблице будет полный жах(труба) из за постоянных обновлений/изменений. Опять же об этом не подумал.

Оба варианта имеют право на жизнь, пока не понимаю какой из вариантов будет более оптимальным. Буду пробовать оба.


ВСЕМ СПАСИБО!
Желаю всем приятных выходных.
.

Итак, вчера запустил таблицы в режиме Unloged и TEMP.
Результаты оказались хуже чем думал и много подводных камней.

По порядку.
1) Если при работе с обычными таблицами время занимало 0,72-0,78 секунды на 1 полный цикл, то при создании этих же таблиц, как не протоколируемых (Unlogged), время уменьшилось до 0,67-0,72, то есть меньше всего на 0,05 секунды на 1 полный цикл. Ну не знаю, имеет ли смысл в таком убыстрении и с теми рисками (для меня это не критично, но эта не то ускорение в работе на которое я рассчитывал). В общем ускорение получилось не ахти какое.

2) С временной таблицей получилось еще интереснее. Время работы при работе с TEMP таблицей увеличилось опять до 0,72-0,77 секунд. В среднем около 0,74-0,75 сек (0,67-0,72 это время без этой таблицы). Но вылезли проблемы. Таблица то создается, и программа с ней работает, но вот посмотреть её я не могу. Для меня это минус! То есть при попытке заглянуть в таблицы из Dbeaver я такой таблицы не вижу. При создании запроса из вне (=psql) и попытки посмотреть такую таблицу - запрос говорит что её нет. В принципе это логично, так как таблица существует только в пределах сессии/рабочего дня (комп на ночь выключается). Но то что её нельзя посмотреть - это БОЛЬШОЙ МИНУС.
3) Про VACUUM + VACUUM FULL то что их нельзя запускать внутри кода обсуждали ранее. Это опять минус. Настроил под временную таблицу персональные :


Таблица перестала пухнуть. Без них было все очень плохо - TEMP таблица пухла на глазах. Причем за 10 минут с 24 кб вырастала до 5 Мб. Ну это ни в какие ворота не лезло.
Затем, в вечернюю паузу, таблица все равно пухнет. Не понимаю почему, предпринял кое какие попытки, сегодня проверю.
.
В общем, выводы следующие - Unlogged table в моем случае БОЛЕЕ предпочтительнее. Вакуум с ними работает в РАЗЫ/десятки разов лучше. Так за целый день размер со 128 кб увеличился всего до 800 кб. Это не сравнить с 24 до 5000 кб при работе с TEMP таблицами.
Опять же к Unlogged table есть визуальный доступ, можно все проверить и сделать запрос вручную из вне.
Скорость работы выросла ну почти никак.

Так что любая теория должна проверяться на практике. Я ожидал гораздо более качественного скачка.
.
Наверное придется делить поток (две программы для обработки одного списка) на две части и в каждом потоке обслуживать 50% от общего списка, тогда время точно сократится до 0,4 секунд.
.

Favn,
Я считаю, что каждая БД имеет свои плюсы и минусы. Это как в фотошопе - один результат можно получить разными путями.
Изучать Redis (м.б. с reJSON, чтобы было удобнее) - нет временных ресурсов. Тут еще с PostgreSQL пилить и пилить, а потом нужно еще Pyton для вывода примитивных графиков, отправки писем, создания отчетов, так что тут еще не на один месяц вперед куча работы.

Что касаемо " Или просто примитвы своего ЯП, если не надо. " я не понял о чем речь.
.