Всем привет. А есть такой тип таблицы который храниться в

оперативной памяти - пусть хоть очищается при редуте сервера?
Ну временная таблица …

unlogged. И да, конечно, они не обязательно хранятся в оперативной памяти. В линуксе это вообще не очень просто -- и потому не очень принято. Но, в общем, поскольку они не синхронизируются на диск никогда -- то если у памяти нет более важных вещей, то они будут висеть только в памяти.

Есть два вида: temporary — временные таблицы, существующие только в рамках одного подключения и не видимые для других подключений Unlogged — полноценные таблицы, видимые всем пользователям, но не пишущие информацию об изменениях своих данных в WAL. Соответственно, после перезагрузки/краха БД данных в ней не будет, сохранится только сама структура. Полагаю, что именно такой кейс Вы и имели в виду

Разве unlogged tables тоже не пишутся на диск? Я думал, у них поведение аналогичное обычным таблицам, но они только в WAL не отражаются, а сами данные всё-таки лежат на диске

У них есть дисковое место, которое под них выделено -- но, вообще говоря, система не обязана это делать. И можэт отложыть запись до лучшых времён.

А как сделать чтобы они в памяти хранились?

Постоянно "прогревать", чтобы на диск не выгружались. Впрочем, это ко всем таблицам относится.

а как же checkpoint?

памяти добавить

Так он WAL записывает в таблицы, а если таблицы нет в WAL...

шта?)

Впрочем, он не обязательно выгружает страницы из памяти (какой бы то ни было).

а как грязные блоки попадают в таблицу на диске? Или не попадают?)

Отправляются сразу в файл при необходимости освободить shared_buffers, насколько я помню.

ну и как это коррелирует с "Постоянно "прогревать", чтобы на диск не выгружались."?

Если постоянно прогревать -- то необходимости освободить shared_buffers не возникнет.

ясно-понятно)

Там будет 10-15 строк, может чуть больше. Я буду у них менять статусы enum. И это будет очень быстро. Т.е. в секунду 3 раза должен сменить у одной строки. Поэтому я подумал о памяти. У меня postgresql память почему-то не кушает. 8 гигов на VDS, 1,5% занято. Может буферный кэш проставить побольше, я так понимаю это параметр shared_buffers = 2GB

И много будет данных в каждой строке?

Нет. 10-15 строк, 5-10 столбцов

А данных, данных-то в столбцах сколько будет? В байтах?

1170 байт сейчас всего в таблице

ОК. И как тогда вы планируете чтобы у вас вашы гигабайты использовались?

Я вам посчитал пример одной таблицы. Временной.

Короче я перегрузил где-то 1/90 в постгресс от БД на MySql. Mysql занимал вместе с индексами 160 Гигов. А 1/90 от объекма занимает 254 мб. Любопытно. Постгресс экономнее походу.

Или вы индэксы забыли какие-то.

В цэлом -- нет, все накладные расходы в нормальных ситуацыях плюс-минус похожы. На порядок отличаться не будут. Собственно, накладные на тапл -- дажэ поменьшэ в mysql (нет xid, нет отдельного primary key). Возможно, там в mysql был index bloat высочайшый.

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

Ну, тогда я просто не вижу -- чего вы хотите. И зачем считаете одну временную таблицу небольшого размера.

Закомментированы обычно дефолтные значения.

Я изначально спрашивал про временные таблицы в памяти. Потому что если я начинаю перебирать у меня скрипт эксепшион выкидывает, "не могу получить строку". Ну и в голове возникло 2 варианта: 1. Не смог создать подключение (сейчас я отработаю этот вариант) - много подключений, пуллер на своей стороне организую. 2. не успевает обработать данные. У меня еще на таблице стоит триггер который обрабатывает дату. Возможно еще дело в нем. В MySql я так же делал с такой же таблицей временной. Все работало. --- Триггер обновления даты и функция ее дергающая BEGIN; CREATE OR REPLACE FUNCTION update_last_work() RETURNS TRIGGER AS $$ BEGIN NEW.last_work = now(); RETURN NEW; END; $$ language 'plpgsql'; COMMIT; -- фукнция которая дергает триггер CREATE TRIGGER update_timestamp_last_work BEFORE INSERT OR UPDATE ON tableTmp FOR EACH ROW EXECUTE PROCEDURE update_last_work();

Dmitry Runov
Я думаю у меня автовакуум не включен.

Можно просто посмотреть show all; Чем думать лишний раз.

В общем -- типичный https://xyproblem.info

Прикольно пишет что включен :) и track_counts тоже включен ...

Спс буду пробовать ...