Можно ли всем строковым полям задавать тип TEXT и повлияет ли это сильно на производительность?

На сколько адекватен подход задавать всем текстовым колонкам тип TEXT?
Что бы не писать каждый раз VARCHAR (255), TEXTили другую длину
Критично ли это для производительности, скорости записи-выборки или чего-то еще?

Дополнительно:

Судя по этой статье можно всегда использовать TEXT вместо CHAR(N) и VARCHAR(N), т.к. производительность особо не страдает.

А если самому пойти в документацию, то можно увидеть следующее:

There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.

Т.е. в производительности разницы нет - только в стоимости хранения. (в отличие от других СУБД)

• По поводу памяти это экономия на спичках использовать VARCHAR или за этим следят?
• MishaXXL, varchar и text - по факту одно и то же, а char(n) как следует из документации самый медленный
• MishaXXL,
  

  По поводу памяти это экономия на спичках использовать VARCHAR или за этим следят?

  Используйте те типы, которые подходят для ваших данных, не с точки зрения производительности сомнительно высчитаной, а с точки зрения стандартов SQL. Это нужно для правильной валидации данных и контроля данных. Объявляя параметр как text, вы не сильно ограничиваете его длину, а значит если понадобится хранить, передавать этот параметр в другую систему вы уже не сможете использовать тип varchar(255), а для другой системы это может быть критично. Чем более вы вносите ограничений в код и данные, тем легче будет ими управлять в будущем.

  Сергей Соловьев,

  varchar и text - по факту одно и то же, а char(n) как следует из документации самый медленный

  несовсем так, как написал выше, всегда выбирайте тот тип, который подходит под ваши данные. char(n) не самый медленный, а может быть даже менее затратный чем varchar, если вы в нем храните подходящие данные. Т.е. если вы храните например 2-х символьный код страны, char(2) - отличное решение, а вот varchar(2) будет затратнее, т.к. будет хранить ненужную здесь длину строки для каждой ячейки. Но, если вы возьмете тип char(255), и будете в нем хранить строки длиной 10 символов, то затраты будут в разы больше, чем для varchar(255). Поэтому используйте те типы, которые подходят для ваших данных.

• Vitsliputsli, опять приходим к "зависит"/"делать так как лучше")
• Сергей Соловьев, перепроверил, должен исправиться, в PostgreSQL тип char реализован по-мудацки, поэтому в этой СУБД его действительно лучше не использовать. Так что вы правильно написали, а мой пример некорректен для PostgreSQL.

text и varchar - это одно и то же на уровне реализации postgresql.

varchar с каким-то разумным ограничением (не бессмысленный взятый с потолка 255 везде, а разумный для этого конкретного поля) тем не менее смысл имеет: куда проще найти ошибку в месте записи данных, чем потом искать, откуда в поле обычно содержащем до 30 символов взялось 10 мегабайт текста (история из практики, да)

Про char ограничусь цитатой письма Tom Lane

Type character(N) is a hangover from the days of punched cards. Don't use it.

Просто забудьте про такой тип данных. Он не только бесполезен, но и вреден.

• Приведу полную цитату:
  
  

  Type character(N) is a hangover from the days of punched cards.
  Don't use it. It has weird semantics concerning trailing spaces,
  which are almost never the behavior you actually want, and cause
  interoperability issues with type text. (Text is Postgres' native
  string type, meaning that unlabeled string constants will tend to
  get resolved to that.)

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

  contract_address character(42) NOT NULL, buyer_address character(42) NOT NULL, seller_address character(42) NOT NULL,

  contract_address character(42) NOT NULL, buyer_address character(42) NOT NULL, seller_address character(42) NOT NULL,

  такому действительно можно рекомендовать лучше вообще не использовать тип char.
  char отличное решение там, где он действительно нужен, где строго определено кол-во символов. но если у вас не высоконагруженное решение, и лишний байт на каждое поле не проблема, то можно всегда использовать varchar.

• оу, не смешите публику, если не знаете, кто такой Tom Lane в IT и для postgresql в особенности.
  

  char отличное решение там, где он действительно нужен, где строго определено кол-во символов. но если у вас не высоконагруженное решение, и лишний байт на каждое поле не проблема, то можно всегда использовать varchar.

  какой такой байт? Нет ни одного сценария, где char(n) займёт хотя бы на один байт меньше, чем varchar(n)

• Melkij, а какая разница для вопроса, какие у него лавры? Если он нормально не объясняет в ответе.
  Но должен исправиться, в PostgreSQL тип char реализован по-мудацки, поэтому в этой СУБД его действительно лучше не использовать, но при нормальной реализации как в других СУБД это не так.
• Подскажи пожалуйста, какая длинна по памяти идет следующая у VARCHARпосле 255?
  Я так понял VARCHAR(256) и VARCHAR(65535) будут занимать одинаковое количество памяти?

  В плане, хочу создать таблицы для постов и сообщений
  И вроде как 255 может оказаться мало для сообщения или заголовка.
  Что возможно нужно до 500.
  И получается нужно создавать VARCHAR(65535)
  Хотя по эффективности памяти выйдет, как VARCHAR(65535) и TEXT, верно?
  Лишь с поправкой, что VARCHARнам тут поможет ограничить лимит длинны сообщения или заголовка, так?

  И часто замечаю лимиты количество символов для сообщений
  Это связанно именно из-за того, что так же выставляются лимиты на сообщения в БД, как VARCHAR(2000) например?
  Или есть еще какая-то связь по определенному количеству памяти, которое эффективно может передаваться при передачи сообщений?

• Для postgresql ничего сакрального в varchar(255) нет. Одна и та же строка длиной 200 символов будет занимать одинаково места будь то поле varchar(220), varchar(255), varchar(300) или text.

  Если интересно закопаться в детали, то строка длиной до 126 байт (здесь именно байт, а не символов) хранится с коротким однобайтовым заголовком. Но этот короткий заголовок применяется исходя из фактической длины данных, независимо от того, как объявлена колонка.

  И часто замечаю лимиты количество символов для сообщений

  Ограничения могут быть как обоснованные реализацией, так и просто взятыми с потолками (тот же самый якобы дефолтный varchar(255) в головах многих разработчиков)
  Заголовок сообщения, наверное, не должен быть гигабайтного размера. Но каким объёмом ограничиться? Обычно это и есть какое-то взятое с потолка значение.