У меня есть таблица в pg как так:
CREATE TABLE t (
a BIGSERIAL NOT NULL, -- 8 b
b SMALLINT, -- 2 b
c SMALLINT, -- 2 b
d REAL, -- 4 b
e REAL, -- 4 b
f REAL, -- 4 b
g INTEGER, -- 4 b
h REAL, -- 4 b
i REAL, -- 4 b
j SMALLINT, -- 2 b
k INTEGER, -- 4 b
l INTEGER, -- 4 b
m REAL, -- 4 b
CONSTRAINT a_pkey PRIMARY KEY (a)
);
Вышеупомянутое составляет в целом 50 байтов за строку. Мой опыт состоит в том, что мне нужны еще 40% к 50% для системы наверху даже без любых созданных пользователями индексов к вышеупомянутому. Так, приблизительно 75 байтов за строку. У меня будут многие, много строк в таблице, потенциально вверх 145 миллиардов строк, таким образом, таблица будет быть продвижением 13-14 терабайт. Какие приемы, если таковые имеются, я мог использовать для уплотнения этой таблицы? Мои возможные идеи ниже...
Преобразуйте real
значения к integer
. Если они могут сохраненный как smallint
, это - сохранение 2 байтов за поле.
Преобразуйте столбцы b.. m в массив. Я не должен искать на тех столбцах, но я действительно должен смочь возвратить значение на один столбец за один раз. Так, если мне нужен столбец g, я мог бы сделать что-то как
SELECT a, arr[5] FROM t;
Я оставил бы свободное место с опцией массива? Был бы штраф скорости?
Какие-либо другие идеи?
Я не вижу ничего, что можно получить (и что-то потерять) при хранении нескольких числовых полей в массиве.
Размер каждого числового типа четко задокументирован, вы должны просто использовать тип наименьшего размера, совместимый с желаемым разрешением диапазона; и это все, что вы можете сделать.
Я не думаю (но не уверен), есть ли какое-либо требование выравнивания байтов для столбцов в строке, в этом случае переупорядочение столбцов может изменить используемое пространство - но я не думаю так.
Кстати, исправление накладных расходов на строку составляет около 23 байта .