Изчисляване и спестяване на място в PostgreSQL

„Колона Тетрис“

Всъщност можете да направитенещо , но това се нуждае от по-задълбочено разбиране. Ключовата дума е подреждане на подравняване . Всеки тип данни има специфични изисквания за подравняване.

Можете да сведете до минимум пространството, което се губи при допълване между колоните като ги нареди благоприятно. Следният (екстремен) пример би загубил много физическо дисково пространство:

CREATE TABLE t (
    e int2    -- 6 bytes of padding after int2
  , a int8
  , f int2    -- 6 bytes of padding after int2
  , b int8
  , g int2    -- 6 bytes of padding after int2
  , c int8
  , h int2    -- 6 bytes of padding after int2
  , d int8)

За да спестите 24 байта на ред, използвайте вместо това:

CREATE TABLE t (
    a int8
  , b int8
  , c int8
  , d int8
  , e int2
  , f int2
  , g int2
  , h int2)   -- 4 int2 occupy 8 byte (MAXALIGN), no padding at the end

db<>цигулка тук
_{Стар sqlfiddle}

Като правило, ако поставите първо 8-байтови колони, а после 4-байтови, 2-байтови и 1-байтови колони, няма как да сбъркате.

boolean , uuid (!) и няколко други типа не се нуждаят от подравняване. text , varchar и други типове "варлена" (променлива дължина) номинално изискват "int" подравняване (4 байта на повечето машини). Но не забелязах подравняване в дисковия формат (за разлика от RAM). В крайна сметка намерих обяснението в бележка в изходния код:

Имайте предвид също, че позволяваме номиналното подравняване да бъде нарушено при съхраняване на "опаковани" варлени; механизмът TOAST се грижи да го скрие от повечето кодове.

Така че "int" подравняването се прилага само когато (евентуално компресирана) база данни, включително единичен водещ дължина-байт, надвишава 127 байта. След това съхранението на varlena превключва на четири водещи байта и изисква "int" подравняване.

Обикновено можете да спестите няколко байта на ред в най-добрия случай, като играете на „column tetris“ . Нищо от това не е необходимо в повечето случаи. Но с милиарди редове това може лесно да означава няколко гигабайта.

Можете да тествате действителния размер на колона/ред с функцията pg_column_size() .
Някои типове заемат повече място в RAM, отколкото на диска (компресиран или „опакован“ формат). Можете да получите по-големи резултати за константи (RAM формат), отколкото за колони на таблицата, когато тествате една и съща стойност (или ред стойности спрямо ред на таблица) с pg_column_size() .

И накрая, някои типове могат да бъдат компресирани или „препечени“ (съхранени извън линията) или и двете.

Режимни разходи за кортеж (ред)

4 байта на ред за идентификатора на елемента – не е предмет на горепосочените съображения.
И поне 24 байта (23 + допълване) за заглавката на кортежа. Ръководството за оформление на страницата в базата данни:

Има заглавка с фиксиран размер (заемаща 23 байта на повечето машини), последвана от незадължителна нулева растерна карта, незадължително поле за идентификация на обекта и потребителските данни.

За допълването между заглавката и потребителските данни трябва да знаете MAXALIGN на вашия сървър - обикновено 8 байта на 64-битова ОС (или 4 байта на 32-битова ОС). Ако не сте сигурни, проверете pg_controldata .

Изпълнете следното във вашата бинарна директория на Postgres за да получите категоричен отговор:

./pg_controldata /path/to/my/dbcluster

Ръководството:

Действителните потребителски данни (колони на реда) започват от отместването, обозначено с t_hoff , което винаги трябва да е кратно на MAXALIGN разстояние за платформата.

Така че обикновено получавате оптимално съхранение, като пакетирате данни в кратни на 8 байта.

Няма какво да спечелите от примера, който сте публикували . Вече е опаковано плътно. 2 байта запълване след последния int2 , 4 байта в края. Можете да консолидирате допълването до 6 байта в края, което няма да промени нищо.

Режимни разходи за страница с данни

Размерът на страницата с данни обикновено е 8 KB. Някакъв излишък/надуване на това ниво също:Остатъците не са достатъчно големи, за да се поберат на друг кортеж, и по-важното мъртви редове или процент, запазен с FILLFACTOR настройка.

Има няколко други фактора за размера на диска, които трябва да се вземат предвид:

• Колко записа мога да съхранявам в 5 MB PostgreSQL на Heroku?
• Не използва ли NULL в PostgreSQL все още ли използва NULL растерна карта в заглавката?
• Конфигуриране на PostgreSQL за производителност на четене

Типове масиви?

Смасива тип, както оценявахте, ще добавите 24 байта надпис за вида. Освен това елементите на масива заемат място както обикновено. Няма какво да спечелите.