История изменений
Исправление vbr, (текущая версия) :
Что значит «хранится менее эффективно»?
Это значит, что там всегда хранится строка фиксированной длины, добитая пробелами, вне зависимости от того, что там должно храниться. И при сравнении эти пробелы будут игнорироваться. Что будет вызывать лишние такты процессора, мелочь, но не нужная.
Но к чему я задал этот вопрос вы кажется не поняли.
Я вопросы не додумываю.
Не понимаете. Нет такого 1бит в виде единицы хранения данных, физически оно займет больше.
https://www.postgresql.org/docs/current/storage-page-layout.html посоветую почитать хотя бы, можно и исходники, если хочется убедиться. Вот прямая цитата:
All table rows are structured in the same way. There is a fixed-size header (occupying 23 bytes on most machines), followed by an optional null bitmap, an optional object ID field, and the user data.
optional null bitmap это как раз те биты, про которые я писал. За заголовком хранятся реальные данные, и, конечно, только те, которые не равны NULL.
Исходная версия vbr, :
Что значит «хранится менее эффективно»?
Это значит, что там всегда хранится строка фиксированной длины, добитая пробелами, вне зависимости от того, что там должно храниться. И при сравнении эти пробелы будут игнорироваться. Что будет вызывать лишние такты процессора, мелочь, но не нужная.
Но к чему я задал этот вопрос вы кажется не поняли.
Я вопросы не додумываю.
Не понимаете. Нет такого 1бит в виде единицы хранения данных, физически оно займет больше.
https://www.postgresql.org/docs/current/storage-page-layout.html посоветую почитать хотя бы, можно и исходники, если хочется убедиться. Вот прямая цитата:
All table rows are structured in the same way. There is a fixed-size header (occupying 23 bytes on most machines), followed by an optional null bitmap, an optional object ID field, and the user data.
optional null bitmap это как раз те биты, про которые я писал.