Postgres. Можно ли ожидать хорошего ускорения, переключив BIGINT на INT?

Question

Эта база данных Postgres содержит таблицы всех размеров до 10 миллионов строк. Почти все имеют первичный ключ BIGINT, считая от 1 и выше.

Поскольку BIGINT имеет 64 бита, но 10 миллионов строк находятся в пределах максимум 2 миллиардов от INT, стоит ли преобразовывать эти столбцы BIGINT в INT ( 32 бита) и SMALLINT (16 бит), чтобы ускорить некоторые тяжелые SQL? Хранение индексов / таблиц более компактно должно дать нам более высокий коэффициент попадания в кэш. Сколько ускорения я могу ожидать, если таковые имеются? И есть ли недостатки, если вы не используете BIGINT? (при условии, что достижение максимального значения INT / SMALLINT никогда не будет проблемой)

Answer 1

Это очень сильно зависит от фактических определений таблиц и индексов. Коммутатор сохраняет 4 байта для столбца, но, поскольку все хранилище выполняется с кратностью 8 байт, его можно проглотить путем выравнивания или освободить 8 байт, если вам повезет.

Стандартный индекс btree, поддерживающий PK не изменится в размере, 4 байта будут потеряны при заполнении выравнивания. Но , если вы используете для дополнительного 4-байтового столбца в покрывающем индексе, это экономит 8 байтов вместо всего 4, что делает индекс кортежа всего 20 байтов вместо 28.

Первичный ключ bigint является только началом. Если есть ссылки на внешние ключи, эффекты умножаются. Или у вас есть многоколоночные индексы, включающие несколько столбцов FK. Тогда переключатель может очень хорошо привести к хорошему ускорению, как вы ищете. Особенно, если кеш-память ограничена. Все зависит.

Если вы уверены, что не будете записывать более 3 ^ 31 чисел (не 2 ^ 32: Postgres использует целое число со знаком, вам также придется использовать отрицательную половину) сверх За время жизни таблицы и вы фактически экономите место в таблицах и индексах, а затем непременно переключаетесь на обычный integer. Я видел реальную разницу много раз. Но вам необходимо некоторое понимание механизмов хранения Postgres, прежде чем с этим возиться.

Связанный:

• Расчет и сохранение пространства в PostgreSQL
• Настройка PostgreSQL для производительности чтения

Answer 2

Только надежный ответ даст только нагрузочный тест, но я ожидаю, что вы не увидите заметного прироста производительности.

bigint - правильный тип данных здесь. Даже если вы уверены, что не исчерпаете предел integer, учтите следующее:

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

• когда-то была пара умных людей, которые думали, что 2 ³² будет намного больше IP-адресов, чем кто-либо когда-либо мог бы нуждаться

С таким маленьким столом, как ваш, экономия места и производительности не будет стоить усилий. С большим столом вам не нужно страдать от необходимости конвертировать его из integer в bigint.

Преждевременная оптимизация - это root всего зла.

Answer 3

Данные обычно хранятся на диске с выравниванием по 8-байтовым границам. Индекс одного столбца на bigint будет такого же размера, как и на int. Для таблицы или многоколоночного индекса может быть возможно упаковать int более плотно, в зависимости от того, какие смежные столбцы можно объединить, чтобы уместиться в 8 байтов.

Изменение производительности, скорее всего, будет небольшим или отсутствует и трудно предсказать. Чтобы узнать ответ, вам придется пройти тест. Но это, вероятно, не стоит времени, которое потребовалось бы, чтобы сделать это.