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