Типы и индексы данных

Question

Есть ли какая-то разница в производительности для вставки, обновления или удаления данных при использовании типа данных TEXT?

Я пошел here и нашел это:

Подсказка: Там нет разницы в производительности между этими тремя типами, кроме от увеличения дискового пространства при использовании пустого мягкого типа, а через несколько дополнительных циклов процессора для проверки длины при хранении в колонке с длиной строки . Хотя характер (n) имеет преимущества в некоторых других системах баз данных, в PostgreSQL нет такого преимущества ; на самом деле символ (n) обычно является самым медленным изиз-за его дополнительных затрат на хранение. В большинстве случаев вместо этого следует использовать текст или символ.

Это заставляет меня думать, что не должно быть разницы в производительности, но мой друг, который гораздо более опытен, чем я, говорит, что вложения, обновления и удаления медленнее для типа данных TEXT.

У меня был стол, который был разделен триггером и функцией, и чрезвычайно сильно проиндексирован, но вставки не шли так медленно.

Теперь у меня есть другая таблица с еще 5 столбцами, все из которых являются текстовыми типами данных, одним и тем же триггером и функцией, без индексов, но вставки ужасно медленны.

Из моего опыта, я думаю, он прав, но что вы, ребята, думаете?

Редактировать # 1: Я загружаю точные точные данные, только вторая версия имеет еще 5 столбцов.

Редактировать # 2: Под «Slow» Я имею в виду с первым сценарием, мне удалось вставить 500 или более строк в секунду, но теперь я могу вставлять только 20 строк в секунду.

Редактировать # 3: Я не добавлял индексы ко второму сценарию, как в первом сценарии, потому что индексы должны замедлять вставки, обновления и удаления из моего понимания.

Редактировать # 4: Я гарантирую, что это точно такие же данные, потому что я их загружаю. Единственное отличие состоит в том, что во втором сценарии есть 5 дополнительных столбцов, все текстовые данные.

Редактировать # 5: Даже когда я удалил все индексы по сценарию 2 и оставили их все по сценарию 1, вставки были еще медленнее на сценарии 2.

Редактировать # 6: Оба сценария имеют одинаковые точный триггер и функция.

Редактировать # 7: Я использую инструмент ETL, Pentaho, для вставки данных, поэтому нет способа показать вам код, используемый для вставки данных.

Я думаю, что у меня могло быть слишком много шагов преобразования в инструменте ETL. Когда я попытался вставить данные в то же преобразование, что и шаги, которые фактически преобразуют данные, он был очень медленным, но когда я просто вставил данные, уже преобразованные в пустую таблицу, а затем вставил данные из этой таблицы в фактическую таблицу I ' м, вставки были намного быстрее, чем сценарий 1 со скоростью 4000 рядов в секунду.

Единственное различие между сценарием 1 и сценарием 2, за исключением увеличения столбцов в сценарии 2, - это количество шагов в преобразовании ETL. В двух сценариях в преобразовании ETL есть два или более шага. В некоторых случаях их еще 50.

Я думаю, что я могу решить свою проблему, уменьшив количество шагов преобразования или поместив преобразованные данные в пустую таблицу, а затем вставив данные из этой таблицы в фактическую таблицу, которую я использую.

Answer 1

PostgreSQL text и character varying те же, за исключением (дополнительного) предела длины для последнего. Они будут выполняться одинаково.

единственные причины, чтобы предпочесть character varying являются

• вы хотите наложить ограничение на длину

• вы хотите, чтобы соответствовать стандарту SQL