Заявленный размер varchar поля оказывают какое-либо влияние в PostgreSQL?
3 ответа
Они идентичны.
Из документации PostgreSQL:
http://www.postgresql.org/docs/8.3/static/datatype-character.html
Совет: между этими тремя типами нет различий в производительности, за исключением увеличенного размера хранилища при использовании типа с пробелом и нескольких дополнительных циклов для проверки длины при сохранении в столбце с ограниченной длиной. Хотя символ (n) имеет преимущества в производительности в некоторых других системах баз данных, он не имеет таких преимуществ в PostgreSQL. В большинстве случаев вместо текста следует использовать изменяющийся текст или символ.
Здесь они говорят о различиях между char (n), varchar (n) и text (= varchar (1G)). Официальная история заключается в том, что нет разницы между varchar (100) и текстом (очень большой varchar).
Нет разницы между varchar(m) и varchar(n) ..
http://archives.postgresql.org/pgsql-admin/2008-07/msg00073.php
Существует разница между varchar(n) и text, хотя, varchar(n) имеет встроенное ограничение, которое должно быть проверено и на самом деле немного медленнее.
http://archives.postgresql.org/pgsql-general/2009-04/msg00945.php
TEXT / это / то же самое, что и VARCHAR без явной длины, текст
"Требования к хранилищу для короткого строка (до 126 байт) - 1 байт плюс фактическая строка, которая включает отступы в случае персонаж. Более длинные строки имеют 4 байта накладные расходы вместо 1. Длинные строки сжаты системой автоматически, поэтому физический требования на диске могут быть меньше. Очень длинные значения также хранятся в фоновые таблицы, чтобы они не мешают быстрому доступу к более коротким значения столбца. В любом случае самая длинная строка символов, которая может храниться около 1 ГБ ».
относится как к VARCHAR, так и к TEXT (поскольку VARCHAR (n) - это всего лишь ограниченная версия TEXT). Искусственное ограничение ваших VARCHARS не дает реальных преимуществ для хранения или производительности (накладные расходы основаны на фактическая длина строки, а не длина базовой varchar), за исключением, возможно, сравнений с подстановочными знаками и регулярными выражениями (но на уровне, где это начинает иметь значение, вам, вероятно, следует искать что-то вроде поддержки полнотекстового индексирования PostgreSQL) .