Коэффициент заполнения для последовательного индекса, который является PK

Question

Да, коэффициент заполнения снова. Я провожу много часов за чтением и не могу решить, какой из факторов лучше для каждого случая. Проблема в том, что я не понимаю, когда и как производится фрагментация. Я перемещаю базу данных с MS SQL Server на PostgreSQL 9.2.

Случай 1) 10-50 вставок / минуту в последовательном (последовательном) ПК, 20-50 чтений / час.

CREATE TABLE dev_transactions
(
  transaction_id serial NOT NULL,
  transaction_type smallint NOT NULL,
  moment timestamp without time zone NOT NULL,
  gateway integer NOT NULL,
  device integer NOT NULL,
  controler smallint NOT NULL,
  token integer,
  et_mode character(1),
  status smallint NOT NULL,
  CONSTRAINT pk_dev_transactions PRIMARY KEY (transaction_id)
)
WITH (
  OIDS=FALSE
);

Случай 2) Аналогичный структурный индекс для последовательной записи PK будет записывать в блоках (один выстрел) ~50 000 регистров каждые 2 месяца, показания 10-50 / мин.

Коэффициент заполнения 50% означает, что при каждой вставке будет создаваться новая страница и переноситься 50% существующих записей на новую страницу создания?

Коэффициент заполнения 50% означает, что при создании новой страницы скопированные записи будут сэкономлены, чтобы избежать вставки между ними?

Новая страница генерируется только если нет места для размещения вставленной записи?

Как видите, я очень смущен; Я был бы признателен за помощь - возможно, это хорошая ссылка для чтения о PostgreSQL и коэффициентах заполнения индекса.

Answer 1

FILLFACTOR

Только с INSERT а также SELECT Вы должны использовать FILLFACTOR из 100 везде.

Нет смысла оставлять пространство для маневра в блоке памяти, если вы не собираетесь "шевелиться" UPDATE s.

Механизм позади FILLFACTOR очень просто INSERT s заполняют только каждую страницу данных (обычно блоки по 8 КБ) до процента, объявленного FILLFACTOR установка. Кроме того, всякий раз, когда вы запускаете VACUUM FULL или же CLUSTER на столе одна и та же комната для маневра восстанавливается. В идеале это позволяет UPDATE s для хранения новых версий строк на одной странице данных, что может существенно повысить производительность при работе с большим количеством UPDATE s. Также полезно в сочетании с горячими обновлениями:

• Избыточные данные в операторах обновления

Если обновлений нет, не тратьте на это место и установите 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 байт - как правило, вы не можете сильно выжать с помощью столбца tetris:

• Расчет и экономия места в PostgreSQL

Кроме того, держать NOT NULL столбцы в начале таблицы для очень маленького бонуса производительности.

Кроме того, ваша таблица имеет 9 столбцов. Это означает дополнительные 8 байтов для расширенного растрового изображения NULL, которое вписалось бы в начальное 1-байтовое растровое изображение NULL всего для 8 столбцов.
Если вы определите et_mode а также tokenNOT NULL все столбцы NOT NULL и битовая карта NULL используется вообще, освобождая 8 байтов.
Это даже работает для каждой строки, если вы не объявляете столбцы NOT NULL, Если все столбцы имеют значения, для этой строки нет растрового изображения NULL. В вашем случае это приводит к парадоксальному эффекту, что заполнение значений для et_mode а также token может уменьшить размер хранилища или, по крайней мере, остаться прежним:

• Занимают ли обнуляемые столбцы дополнительное пространство в PostgreSQL?

Основной источник информации: руководство по базам данных физического хранения.

Сравните размер строк (заполненных значениями) с исходной таблицей, чтобы получить окончательное доказательство:

SELECT pg_column_size(t) FROM dev_transactions t;