В PostgreSQL есть тип varchar без указания длины. По производительности он быстрей чем char(n) и равен varchar(n):
http://stackoverflow.com/questions/7320316/why-specify-a-length-for-character-varying-types

Нам бы такой тоже не помешал, уже :)

Опять хочется чтобы было по-человечески.

Симонов ДенисПроизводительность при работе с BLOB это уже второй вопрос.Это делает его использование неприемлимым. Плюс отсутствие индексов по ним.

А вот как хочется:
http://www.postgresql.org/docs/9.3/static/datatype-character.html The storage requirement for a short string (up to 126 bytes) is 1 byte plus the actual string, which
includes the space padding in the case of character. Longer strings have 4 bytes of overhead instead
of 1. Long strings are compressed by the system automatically, so the physical requirement on disk
might be less. Very long values are also stored in background tables so that they do not interfere with
rapid access to shorter column values. In any case, the longest possible character string that can be
stored is about 1 GB. (The maximum value that will be allowed for n in the data type declaration
is less than that. It wouldn’t be useful to change this because with multibyte character encodings
the number of characters and bytes can be quite different. If you desire to store long strings with no
specific upper limit, use text or character varying without a length specifier, rather than making
up an arbitrary length limit.)

Tip: 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 .

Dimitry SibiryakovNickDeeхочется чтобы было по-человечески.
Звучит как "без необходимости применять мозг".

Ну допустим для ФИО я знаю что оно в 99.9999% случаев в 100 символов войдёт, GUID стопроцентно войдёт в 32.
А вот во сколько символов уложится число произвольной длины уже не знаю (я понимаю, что хранить числа эффективней в бинарном виде). Возможно хватит varchar(1000), а возможно и varchar(32000) не хватит. Но в 99.9% случаев там будут лежать числа от 1 до 100 цифр. Пользователю предложим смириться с просадкой производительности у FB при работе с длинными варчарами? Или если у него вдруг иногда будут числа под сто тыщ цифр, то предложим ему BLOB? Но тогда он бонусом получит ещё просадку, в том числе и для коротких значений. Или просто предложим ему не хранить в БД длинные числа, чтобы производительность не страдала? :)
Имхо должно быть так, чтобы на одних и тех же данных движок вёл себя одинаково, независимо от того какой там N у варчара прописан, и прописан ли.
Это будет архитектурно-правильная позиция.

kdvDimitry SibiryakovМаркетинговое враньё. Читать данные, уложенные на отдельных страницах по определению не может быть так же быстро.
кстати, да, к сожалению, дока по PG этим страдает (см выше, и вроде есть другие штуки, которые тупо умалчиваются).
In any case, the longest possible character string that can be stored is about 1 GB.

sql.ru рекоммендует text вместо varchar(n).
Короче потестировать нужно. Хотя постгревцы наверняка за 10 лет уже протестировали это. Хотя с другой стороны не факт, может они документации на слово верят, и втихую используют text не зная что он "на самом деле дико медленный, в чём неоднократно убеждались парни из FB-тусовки на примере использования движка FB" :)

ТаблоидNickDee,

а ты зачем сделал вид, что ничего не увидел ?
Я увидел :)
Но я с postgreSQL только вчера начал, причём с документации.
Сегодня-завтра может руки дойдут до ознакомления с тулзами и генерации тестовых данных с их помощью. А может и не дойдут так быстро.
Вот тут есть кой-какие бенчмарки: http://www.depesz.com/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/ .

Залил 10 записей в табличку с полем типа text(varchar без N). По 100 миллионов символов на запись.
При create index была выдана ошибка:
SQL Error: ОШИБКА: строка индекса требует байт: 1144712, при максимуме: 8191
Почему он поломался - я не знаю. Ведь можно было построить индекс по первым N символам (пусть даже по 8191, но я бы лучше задавал это N в create index), а остальные символы добывать из записи при непосредственном сравнении. Никто не хочет делать по-взрослому :) Или просто не придумали ещё... :)

kdvNickDee при максимуме: 8191
а я предупреждал. значит, "безразмерная строка" до сих пор не может превышать размер страницы.
Я ж туда 100М текста залил в поле.
А если бы заливал туда строки по 100 символов длиной, то и данные бы хранились по-другому и индекс бы создался.

Симонов ДенисNickDee,

гораздо интереснее что будет если ты сначала создашь индекс, а потом попробуешь залить 100М текста
Фигня получится. Больше 8К не зальёшь.
Я ж говорю, что нужно использовать в ключе индекса только первые N символов, и нет проблем.

А что будет в FB? В FB индекс для varchar(2048) создаётся, а для varchar(4096) уже нет. При пустой таблице.
Если бы даже сейчас сделать в FB возможность создания индексов для полей varchar(32000) и чтобы не получался гигантский расход памяти и просадка по производительности, то будет всем профит. Можно будет спокойно для полей с неизвестным количеством символов ставить 32000.
Т.е. я предлагаю чтобы N в varchar(N) не влияла на производительность и расход памяти, и не влияла на возможность создания индекса. А чтобы стала лишь ограничителем длины.
А то сейчас получается что пользователь указывая N ещё и настраивает производительность, и управляет расходом памяти, причём по неизвестным ему формулам :)

Симонов ДенисNickDeeЯ ж говорю, что нужно использовать в ключе индекса только первые N символов, и нет проблем.

и выдаст твой индекс фигню. Особенно здорово будет попытаться сделать такой индекс уникальным.

Индекс выдаст всё нормально, просто если он будет не по полной строке, то для таких длинных занчений придётся лезть в данные за окончательным вердиктом (> или < или =).
Уникальность - это про "=".
Симонов ДенисNickDeeА что будет в FB? В FB индекс для varchar(2048) создаётся, а для varchar(4096) уже нет. При пустой таблице.

по крайней мере FB не врёт что для некого безразмерного типа вы получаете только преимущества.Вопрос не в том, врёт или нет. Вопрос в том, что даже если в varchar(32000) лежит 10 символов, то ресурсы от компа часто требуются как на 32000 символа. Т.е. varchar(32000) в большинстве случаев кушает ресурсы примерно так же, как char(32000), независимо от длины строки в данных, т.е. кушает почти всегда по максимуму (на 32000).

kdvNickDee Т.е. varchar(32000) в большинстве случаев кушает ресурсы примерно так же, как char(32000), независимо от длины строки в данных
в смысле?
Размеры буферов, их обнуление и заполнение данными.

БД с page_size 16k.
Есть табличка:

, без индексов.
В ней миллион записей. В каждой записи поле S = 'A';
Какой размер БД?
при N = 1 он равен 58mb.
при N = 32000 он равен 583mb.
Т.е. одни и те же данные хранятся в БД с разной степенью эффективности. Разница в 10 раз. Т.е. на такую БД нужно в 10 раз больше оперативки чтобы свопа не было. При одних и тех же данных.


execute and fetch all:
Для N = 1:

Для N = 32000:

6 гигабайт не хватило на сортировку при N=32000. Хорошо что винт SSD, а то бы это получилось не 36 секунд, а минут 5.
При N=2048 на сортировку ушло 4 GB временных файлов, но фетч не прошёл, т.к. IBExpert-у не хватило памяти (он тоже зачем-то отжирает по максимуму памяти, на все N символов, не знаю уж зачем)

Короче вот :)

kdvТаблоидпри сортировках паддинг данных будет до декларированной длины поля
я в курсе, вопрос в том, как это обходит постгрес. Вначале вычисляет макс строку, а только потом сортирует?
А зачем вычислять макс строку? И зачем нужен паддинг? Я просто представляю себе - мне нужно взять из файла строки и посортировать... зачем мне делать их паддинг? Или при записи отсортированных строк в другой текстовый файл...
Я максимум готов записать длину строки и её бинарное представление. Паддить её перед записью не готов. То же и с чтением: читать, а потом избавляться от паддинга, который был сделан предыдущим записывающим... уж лучше договориться с записывающим чтобы не паддил :)