Współczynnik wypełnienia dla indeksu sekwencyjnego, którym jest PK

FILLFACTOR

Tylko z INSERT i SELECT powinieneś użyć FILLFACTOR z 100 wszędzie.

Nie ma sensu opuszczać miejsca do poruszania się po bloku pamięci, jeśli nie zamierzasz "poruszać się" za pomocą UPDATE s.

Mechanizm stojący za FILLFACTOR jest bardzo prosty. INSERT s wypełnić każdą stronę danych (zazwyczaj bloki 8 kb) tylko do wartości procentowej zadeklarowanej przez FILLFACTOR ustawienie. Również za każdym razem, gdy uruchomisz VACUUM FULL lub CLUSTER na stole przywrócono ten sam pokój do poruszania się na blok. Idealnie, pozwala to na UPDATE s do przechowywania nowych wersji wierszy na tej samej stronie danych, co może zapewnić znaczny wzrost wydajności w przypadku wielu UPDATE s. Korzystne również w połączeniu z H.O.T. aktualizacje :

• Zbędne dane w wyciągach aktualizacji

Jeśli nie ma nie aktualizacje, nie marnuj miejsca na to i ustaw FILLFACTOR = 100 .

Podstawowe źródło informacji:podręcznik CREATE TABLE lub CREATE INDEX .

Inna optymalizacja

Ale możesz zrobić coś innego - skoro wydajesz się być frajerem optymalizacji... :)

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));

Optymalizuje to tabelę pod kątem wyrównania danych i unika dopełnienia dla typowego serwera 64-bitowego i oszczędza kilka bajtów, prawdopodobnie średnio tylko 8 bajtów - zazwyczaj nie można wycisnąć zbyt wiele za pomocą "kolumny tetris:

• Obliczanie i oszczędzanie miejsca w PostgreSQL

Zachowaj także NOT NULL kolumny na początku tabeli, aby uzyskać bardzo małą premię za wydajność.

Ponadto Twoja tabela ma 9 kolumn . Oznacza to dodatkowe 8 bajtów dla rozszerzonej bitmapy NULL - co pasowałoby do początkowej 1-bajtowej bitmapy NULL dla zaledwie 8 kolumn .
Jeśli zdefiniujesz et_mode i token NOT NULL , wszystkie kolumny są NOT NULL a bitmapa NULL jest używana w ogóle, zwalniając 8 bajtów.
To działa nawet na wiersz, jeśli nie zadeklarujesz kolumn NOT NULL . Jeśli wszystkie kolumny mają wartości, nie ma mapy bitowej NULL dla tego wiersza. W twoim przypadku prowadzi to do efektu paradoksu polegającego na wypełnianiu wartości dla et_mode i token może zmniejszyć rozmiar pamięci mniejszy lub przynajmniej pozostań taki sam:

• Nie dopuszczaj do zerowania kolumny zajmują dodatkowe miejsce w PostgreSQL?

Podstawowe źródło informacji:podręcznik dotyczący fizycznego przechowywania bazy danych .

Porównaj rozmiar wierszy (wypełnionych wartościami) z oryginalną tabelą, aby uzyskać ostateczny dowód:

SELECT pg_column_size(t) FROM dev_transactions t;