Как вы думаете, какой дизайн работает быстрее в PostgreSQL?
Создание таблицы из 15 столбцов varchars и т.п., но размещение всех столбцов TEXT в отдельной таблице со ссылкой fkey обратно на эту таблицу. И давайте представим, что вы хотите найти запись с идентификатором «4», но затем вернуть все строки, включая данные из столбцов TEXT в объединенной таблице. А давайте представим, что в таблицах 500 000 строк.
Создание таблицы из 15 столбцов varchars и т.п. и включение столбцов TEXT в ту же таблицу. Опять же, представьте то же самое, что и выше - возьмите запись с идентификатором 4 и вытащите полную запись, а в таблице 500 000 строк.
Я имею в виду, что в большинстве баз данных, как я понимаю, когда вы опускаетесь на физический уровень того, как работают эти столбцы TEXT, они фактически сохраняют небольшой идентификатор в столбце таблицы в каждой строке, и этот идентификатор переходит в отдельный, эксклюзивный блок страницы (или другая номенклатура) в базе данных. Итак, мне кажется, что вариант B будет работать быстрее, потому что нет необходимости в накладных расходах на соединение fkey, и потому что столбцы TEXT на самом деле не занимают больше, чем целочисленное пространство в этом столбце в данной таблице - и это целое число является ключом в базе данных к блоку страницы где-то еще.


(B) верно по причине, указанной в самом вопросе.
PostgreSQL не обрабатывает текстовые столбцы так же, как другие СУБД.
Из их документов:
Tip: There are no performance differences between these three types, apart from increased storage size when using the blank-padded type, and a few extra cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, it has no such advantages in PostgreSQL. In most situations text or character varying should be used instead.
+1 за то, что выкопал точную фразу, которую собирался сделать, когда прочитал вопрос!