Увеличивает ли настройка «NOT NULL» в столбце в postgresql производительность? - PullRequest
8 голосов
/ 03 августа 2009

Я знаю, что это хорошая идея в MySQL. Если я правильно помню, в MySQL это позволяет индексам работать более эффективно.

Ответы [ 3 ]

17 голосов
/ 21 сентября 2011

Настройка NOT NULL сама по себе не влияет на производительность. Несколько циклов для проверки - неактуально.

Но вы можете улучшить производительность, фактически используя NULL вместо фиктивных значений. В зависимости от типов данных вы можете сэкономить много дискового пространства и оперативной памяти , тем самым ускоряя ... все.

Нулевое растровое изображение выделяется, только если в строке есть какие-либо значения NULL. Это один бит для каждого столбца в строке (NULL или нет). Для таблиц до 8 столбцов нулевое растровое изображение фактически полностью свободно, используя резервный байт между заголовком кортежа и данными строки. После этого пространство выделяется кратно MAXALIGN (обычно 8 байтов, охватывающих 64 столбца). Разница потеряна для заполнения. Таким образом, вы платите полную (низкую!) Цену за первое значение NULL в каждой строке . Дополнительные значения NULL могут только сэкономить место.

Минимальное требование к памяти для любого ненулевого значения составляет 1 байт (boolean, "char", ...) или, как правило, значительно больше, плюс (возможно) заполнение для выравнивания. Прочтите типы данных или проверьте подробности в системной таблице pg_type.

Подробнее о нулевом хранилище:

12 голосов
/ 03 августа 2009

Это всегда хороший идеал, чтобы столбцы не были равны NULL, если вы можете избежать этого, потому что семантика использования очень грязная; см. Что такое NULL? , чтобы обсудить, как они могут привести к неприятностям.

В версиях PostgreSQL до 8.2 программное обеспечение не знало, как выполнять сравнения по наиболее распространенному индексу типов (b-дереву) таким образом, чтобы в них можно было найти значения NULL. В соответствующем бите документации по типам индексов вы можете увидеть, что описано как "но обратите внимание, что IS NULL не эквивалентно = и не индексируется". Недостатком этого является то, что если вы укажете запрос, который требует включения значений NULL, планировщик может не выполнить его, используя очевидный индекс для этого случая. В качестве простого примера, если у вас есть оператор ORDER BY, который можно ускорить с помощью индекса, но ваш запрос также должен возвращать значения NULL, оптимизатор не может использовать этот индекс, поскольку в результате будут отсутствовать любые данные NULL - и поэтому будьте неполными и бесполезными. Оптимизатор знает об этом и вместо этого будет выполнять неиндексированное сканирование таблицы, что может быть очень дорогим.

PostgreSQL улучшил это в 8.3 , «условие IS NULL для столбца индекса может использоваться с индексом B-дерева». Таким образом, ситуации, когда вы можете сжечь, пытаясь проиндексировать что-либо со значениями NULL, были уменьшены. Но так как семантика NULL все еще очень болезненна, и вы можете столкнуться с ситуацией, когда даже планировщик 8.3 не делает того, что вы ожидаете из-за них, вам все равно следует использовать NOT NULL, когда это возможно, чтобы снизить ваши шансы на выполнение плохо оптимизированного запроса. .

2 голосов
/ 03 августа 2009

Нет, если вы на самом деле не храните NULL в таблице, индексы будут выглядеть одинаково (и одинаково эффективно).

Установка для столбца NOT NULL имеет много других преимуществ, поэтому вам следует всегда установить его, если вы не планируете хранить в нем NULL: -)

...