Является ли VARCHAR(100) лучше, чем VARCHAR(500) с точки зрения производительности? А как насчет использования диска?
Сегодня мы говорим о PostgreSQL, а не о какой-то базе данных когда-то в истории.
Влияет ли заявленный размер поля varchar на PostgreSQL?
Ответы (3)
Они одинаковые.
Из документации PostgreSQL:
http://www.postgresql.org/docs/8.3/static/datatype-character.html
Совет. Между этими тремя типами нет различий в производительности, за исключением увеличения размера хранилища при использовании типа с заполнением пробелами и нескольких дополнительных циклов для проверки длины при сохранении в столбец с ограничениями по длине. В то время как у character(n) есть преимущества в производительности в некоторых других системах баз данных, у него нет таких преимуществ в PostgreSQL. В большинстве ситуаций вместо этого следует использовать текстовые или символьные варианты.
Здесь они говорят о различиях между char(n), varchar(n) и text (= varchar(1G)). Официальная версия состоит в том, что нет никакой разницы между varchar(100) и текстом (очень большой varchar).
person
the.jxc
schedule
01.07.2009
Я говорю о VARCHAR(m) и VARCHAR(n), а не о VARCHAR и CHAR, на что вы указываете.
- person ibz; 01.07.2009
Проверьте еще раз. Они ссылаются на ТРИ, являющихся идентичными. т.е. производительность varchar(n) такая же, как у текста, то есть varchar(LOTS). Единственная разница между типами THREE заключается в заполнении и ограничении длины. Ни один из них не применяется между varchar (100) и varchar (500), поэтому они говорят, что они одинаковы.
- person the.jxc; 01.07.2009
Да, они упоминают все три, но настаивают только на двух. На самом деле я задал этот вопрос на SO именно потому, что меня не устраивал этот конкретный абзац в документе, и я искал более проницательное объяснение. И нет, TEXT не совпадает с VARCHAR(LOTS). ТЕКСТ хранится вне строки. По крайней мере, AFAIK.
- person ibz; 01.07.2009
Как говорится в упомянутом документе и как повторяет james2vegas, любое длинное поле может быть сохранено в фоновой таблице.
- person the.jxc; 03.07.2009
Хорошо, кажется, два других человека согласны с этим, так что я думаю, что это правильно в конце концов. Извините, но документация действительно не очень понятна, поэтому вначале я не хотел считать документацию ответом.
- person ibz; 03.07.2009
Нет никакой разницы между 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
person
rfusca
schedule
02.07.2009
ТЕКСТ /то же самое, что и VARCHAR без явного указания длины, текст
«Требование к хранению для короткой строки (до 126 байтов) составляет 1 байт плюс фактическая строка, которая включает пробел в случае символа. Более длинные строки имеют 4 байта служебных данных вместо 1. Длинные строки сжимаются системой. автоматически, поэтому физические требования к диску могут быть меньше.Очень длинные значения также хранятся в фоновых таблицах, чтобы они не мешали быстрому доступу к более коротким значениям столбцов.В любом случае, самая длинная возможная строка символов, которую можно сохранить, составляет примерно 1 ГБ».
относится как к VARCHAR, так и к TEXT (поскольку VARCHAR(n) — это всего лишь ограниченная версия TEXT). Искусственное ограничение ваших VARCCHARS не дает реальных преимуществ для хранения или производительности (накладные расходы основаны на фактической длине строки, а не на длине базового varchar), за исключением, возможно, сравнений с подстановочными знаками и регулярными выражениями (но на уровне, где это начинает важно, вам, вероятно, следует обратить внимание на что-то вроде поддержки полнотекстового индексирования PostgreSQL).
person
Community
schedule
01.07.2009
