В PostgreSQL: быстрее ли включать столбцы ТЕКСТ в одну и ту же таблицу, а не в отдельную таблицу?

Как вы думаете, какой дизайн работает быстрее в PostgreSQL?

  1. Создание таблицы из 15 столбцов varchars и т.п., но размещение всех столбцов TEXT в отдельной таблице со ссылкой fkey обратно на эту таблицу. И давайте представим, что вы хотите найти запись с идентификатором «4», но затем вернуть все строки, включая данные из столбцов TEXT в объединенной таблице. А давайте представим, что в таблицах 500 000 строк.

  2. Создание таблицы из 15 столбцов varchars и т.п. и включение столбцов TEXT в ту же таблицу. Опять же, представьте то же самое, что и выше - возьмите запись с идентификатором 4 и вытащите полную запись, а в таблице 500 000 строк.

Я имею в виду, что в большинстве баз данных, как я понимаю, когда вы опускаетесь на физический уровень того, как работают эти столбцы TEXT, они фактически сохраняют небольшой идентификатор в столбце таблицы в каждой строке, и этот идентификатор переходит в отдельный, эксклюзивный блок страницы (или другая номенклатура) в базе данных. Итак, мне кажется, что вариант B будет работать быстрее, потому что нет необходимости в накладных расходах на соединение fkey, и потому что столбцы TEXT на самом деле не занимают больше, чем целочисленное пространство в этом столбце в данной таблице - и это целое число является ключом в базе данных к блоку страницы где-то еще.

За пределами сигналов Angular: Сигналы и пользовательские стратегии рендеринга
За пределами сигналов Angular: Сигналы и пользовательские стратегии рендеринга
TL;DR: Angular Signals может облегчить отслеживание всех выражений в представлении (Component или EmbeddedView) и планирование пользовательских...
Sniper-CSS, избегайте неиспользуемых стилей
Sniper-CSS, избегайте неиспользуемых стилей
Это краткое руководство, в котором я хочу поделиться тем, как я перешел от 212 кБ CSS к 32,1 кБ (сокращение кода на 84,91%), по-прежнему используя...
10
0
1 666
2

Ответы 2

(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 за то, что выкопал точную фразу, которую собирался сделать, когда прочитал вопрос!

some 30.12.2008 01:41

Другие вопросы по теме