shared_buffers

да, блок перекладывается в структуру которая находится в shared buffers.
подробнее см. тут  https://www.postgresql.org/docs/current/storage-page-layout.html

коротко и схематично тут 8.1.3
http://www.interdb.jp/pg/pgsql08.html

спасибо. читаю. но это ведь лишние затраты. мы считали. переложили все в память(т.е тратим на копировании). потом что-то в памяти пришлось изменить(скажем 1 байт) и мы вынуждены переписать на блок весь диск в 8К полностью!

возможно ли обновить сразу несколько jsonb полей со ссылкой на эти поля в запросе ?

если у вас есть идеи как сделать постгрес лучше, вы можете отправить свои предложения в список рассылки pgsql-hackers

а вобще там все чуть немного сложнее и есть разные ситуации где нет совершенно оптимального поведения для всех случаев

виртуальная память линукса оперирует только страницами по 4KB,
блочные устройства в зависимости оттипа устройства тоже оперируют блоками разных фиксированных размеров и т.д.

> переложили все в память(т.е тратим на копировании). потом что-то в памяти пришлось изменить(скажем 1 байт) и мы вынуждены переписать на блок весь диск в 8К полностью

это не всегда так... в общих чертах, постгрес пишет на диск только WAL журнал, а то что касается data файлов, их изменение происходит в shared buffers и сбрасывается на диск только при контрольных точках (checkpoints). но опять жэ это в общих чертах... все может отличаться от типа таблиц (обычные, временные, unlogged), настроек постгреса, настроек системы

вторую ссылку что я вам скинул, эту книуг лучше прочитать полностью, чтобы иметь более полное представление об устройстве постгреса

спасибо. пока мне непонятно можно ли было сделать иначе. с одной стороны все логично. считали блок. положили его в памяти в другую структуру. и когда надо переписали старое место в файле полностью. альтернатива тут какая? не создавать дополнительных структур и работать напрямую с куском файла. например у меня есть индекс из 16 блоков. вот я прочел корень с диска. у меня же все равно там в двоичном формате все лежит. мне нужно десерелиазовать.

shared_buffers вроде хранит данные в том же виде, что и на диске

+ фоновая запись?

> положили его в памяти в другую структуру. и когда надо переписали старое место в файле полностью.

вот в этом месте, непосредственно после изменения в памяти переписывания в файле не происходит - эта работа асинхронная и перекладывается на контрольную точку, когда все накопившиеся изменения из памяти (shared buffers) едут на диск

Плюс ко всему прочему читать все время с диска, при конкурентном доступе плохая идея. Система то не под монопольную работу рассчитана.
Кроме того, что несколько клиентов спрашивает, так еще и сам постгрес подходящие вещи расспаралеливает

но на диске ведь они в последовательности байт. тогда это должен быть массив байт?

блин написал такую портянку текста... потом понял что пересказываю interdb.jp 😂
вобщем прочитайте её на предстоящих выходных - многие вопросы отпадут сами собой

эх. жаль портянку стерли (.

вот он десереализует их https://github.com/postgres/postgres/blob/678d0e239b67174f349a401ea7dcecabb3c5b137/src/include/access/htup_details.h#L152

Да. Щас сразу найти не могу. Где то тема была про параллельное сканирование индекса, когда он сканируется в многопоток и у нескольких потоков результат ссылается на одни и те же блоки данных и оптимизируется соответственно путем помещения в shared_buffers в первозданном виде