Фактор на запълване за последователен индекс, който е PK

FILLFACTOR

Само с INSERT и SELECT трябва да използвате FILLFACTOR от 100 навсякъде.

Няма смисъл да оставяте място за мърдане на блок памет, ако няма да "мърдате" с UPDATE с.

Механизмът зад FILLFACTOR е много проста. INSERT запълва само всяка страница с данни (обикновено блокове от 8 kb) до процента, деклариран от FILLFACTOR настройка. Също така, когато стартирате VACUUM FULL или CLUSTER на масата се възстановява същата стая за мърдане на блок. В идеалния случай това позволява UPDATE s за съхраняване на нови версии на редове в същата страница с данни, което може да осигури значително повишаване на производителността при работа с много UPDATE с. Също така е полезен в комбинация сH.O.T. актуализации :

• Излишни данни в отчети за актуализиране

Ако не актуализации, не губете място за това и задайте FILLFACTOR = 100 .

Основен източник на информация:ръководството за CREATE TABLE или CREATE INDEX .

Друга оптимизация

Но можете да направите нещо друго - тъй като изглежда, че сте глупак за оптимизация ... :)

CREATE TABLE dev_transactions
( transaction_id serial PRIMARY KEY,
  gateway integer NOT NULL,
  moment timestamp NOT NULL,
  transaction_type smallint NOT NULL,
  status smallint NOT NULL,
  device integer NOT NULL,
  controler smallint NOT NULL,
  token integer,
  et_mode character(1));

Това оптимизира вашата таблица по отношение на подравняването на данните и избягва подплънките за типичен 64-битов сървър и спестява няколко байта, вероятно само 8 байта средно - обикновено не можете да изстискате много с „тетрис с колона:

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

Освен това запазете NOT NULL колони в началото на таблицата за много малък бонус за ефективност.

Освен това вашата таблица има 9 колони . Това означава допълнителни 8 байта за разширеното NULL bitmap - което ще се побере в първоначалното 1-байтово NULL растерно изображение само за 8 колони .
Ако дефинирате et_mode и token NOT NULL , всички колони са NOT NULL и растерното изображение NULL изобщо се използва, освобождавайки 8 байта.
Това дори работи за ред, ако не декларирате колоните NOT NULL . Ако всички колони имат стойности, няма NULL растерно изображение за този ред. Във вашия случай това води до парадоксалния ефект, че попълването на стойности за et_mode и token може да направи размера на хранилището ви по-малък или поне да остане същото:

• Направете nullable колоните заемат допълнително място в PostgreSQL?

Основен източник на информация:ръководството за физическо съхранение на бази данни .

Сравнете размера на редовете (попълнени със стойности) с вашата оригинална таблица, за да получите окончателно доказателство:

SELECT pg_column_size(t) FROM dev_transactions t;