PostgreSQL домены как хранятся?

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

понимаю такие предположения, просто хочется некой уверенности.
Может всё же найдутся разработчики PG которые смогут сообщить информацию с «низкого уровеня»
P.S. можно конечно воспользоваться в подобном случае битовым полем ( bit(x) ). Но в этом случае больше мороки по преобразованию. И может быть компактифицирование уже встроено и можно не городить излишков.

Тебе там что, нужно хранить такое адовое количество enum-ов что это прям имеет значение? С диска-то оно всё равно будет читаться блоками не меньше 512 или 4096 байт

пусть читаются хоть по 4к, это не мешает. А вот сохранять... - размеры дисков, увы, не резиновые.
Впрочем судя по рассылке pg - там вообще идет выравнивание по 4байта. Хорошо бы это выравнивание на всю запись, а не на конкретное поле этой записи. А то вообще как то дико будет смотреться.

Сдаётся мне что ты занимаешься преждевременной оптимизацией. Ты вообще уверен что у тебя данные будут занимать больше места чем всякая там метаинформация?

текущая база >600G, хоть и не много, но если обновляем в целом, то почему бы и нет.

текущая база >600G

Так это ни о чём.

Т.е. если колонка может хранить только числа 1, 2 и 3. И это ограничение встроено или в таблицу или в домен, то означает ли что реально это значение храниться КОМПАКТНО в два бита.

Тип данных какой? Инт? Ну вот там и будет храниться инт. Там были какие-то битовые поля, они и хранятся по биту на флаг, от x байт минимум. Не думаю, что кто-то будет за тебя оптимизировать, потому что поменял ты домен, стали у тебя храниться числа до 18 и всё, надо всё сдвигать, гг.

Изначальная база была mysql, и тип был tinyint.
Ладно похоже меня убедили, что ради изысков производительностью рисковать не будут. И скорее будет оптимизация(расширение) по 4 байта нежели компактификация.

Сколько записей у тебя в таблице и какая структура? Мб там весь объем есть какой-нибудь char(500)

сорри, чуть позже.
В целом таблица была дефолтная для flow-tools(flow-export) для варианта mysql.
Там всё было очень запущено. Вот и привожу в порядок.

там вообще идет выравнивание по 4байта

Буквально сегодня ночью читал:
https://habr.com/ru/companies/tensor/articles/498292/
и https://habr.com/ru/companies/ruvds/articles/525412/

Из первой:

SELECT pg_column_size(ROW(
  '0000-0000-0000-0000-0000-0000-0000-0000'::uuid
, 0::smallint
, '2019-01-01'::date
));
-- 48 байт

SELECT pg_column_size(ROW(
  '2019-01-01'::date
, '0000-0000-0000-0000-0000-0000-0000-0000'::uuid
, 0::smallint
));
-- 46 байт

Откуда набежала пара лишних байт в первом случае? Все просто — 2-байтовый smallint выравнивается по 4-байтовой границе перед следующим полем, а когда стоит последним — выравнивать нечего и незачем.

Люди, оказывается, поля местами переставляют чтобы выгадать чуть-чуть в объеме )

Не должно, т.к. ограничения это дополнительная проверка на вводимые данные, на формат записи оно не влияет. А поскольку ограничения могут вводиться, удаляться и модифицироваться, то привязывать к ним размер записи было бы очень странно.

Если ты используешь тип данных, который может принимать всего несколько значений, то да, тут база может учитывать это при определении размера записи. Но скорее всего этого нет, потому как bool у них может занимать 1 байт (/postgresql-15.2/src/include/c.h):

/* ----------------------------------------------------------------
 *                              Section 2:      bool, true, false
 * ----------------------------------------------------------------
 */

/*
 * bool
 *              Boolean value, either true or false.
 *
 * We use stdbool.h if available and its bool has size 1.  That's useful for
 * better compiler and debugger output and for compatibility with third-party
 * libraries.  But PostgreSQL currently cannot deal with bool of other sizes;
 * there are static assertions around the code to prevent that.
 *
 * For C++ compilers, we assume the compiler has a compatible built-in
 * definition of bool.
 *
 * See also the version of this code in src/interfaces/ecpg/include/ecpglib.h.
 */

#ifndef __cplusplus

#ifdef PG_USE_STDBOOL
#include <stdbool.h>
#else

#ifndef bool
typedef unsigned char bool;
#endif

#ifndef true
#define true    ((bool) 1)
#endif

#ifndef false
#define false   ((bool) 0)
#endif

#endif                                                  /* not PG_USE_STDBOOL */
#endif                                                  /* not C++ */

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

Размер базы в 600GiB это немного, она вся поместится в NVME за 100$.

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

Если есть желание попердолиться, можно попробовать например какую-то другую СУБД. Я ведь правильно понял что данные не реляционные по сути? Слышал для подобных штук сейчас модно использовать clickhouse, но это не точно

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

Как я понял у ТСа append-only данные, это снимает многие проблемы