数据类型和索引

Question

当您使用TEXT数据类型时，是否存在用于插入，更新或删除数据的某种性能差异？

我去here，发现这个：

提示：使用空白填充类型时，和 一些额外的CPU周期，从增加的存储空间有这三种类型之间没有性能差别，除了 在存储到长度受限的列时检查长度。尽管字符（n）在其他一些数据库系统中具有很好的性能，但在PostgreSQL中不存在这样的优势 ;实际上字符（n）通常是三个中最慢的，因为它有额外的存储成本。在大多数情况下，应该使用文字 或改变字符。

这让我相信应该没有性能差异，但我的朋友比我更有经验，他说插入，更新和删除对TEXT数据类型来说比较慢。

我有与触发和功能分区，并极其严重索引的表，但刀片没有去慢。

现在我有另一个表，有5分列所有这一切都是文本数据类型，完全相同的触发器和功能，没有指标，但刀片是非常缓慢的。

从我的经验，我认为他是正确的，但是你们觉得呢？

编辑＃1： 我上传完全相同的数据，只是第二个版本有5个列。

编辑＃2： 通过“慢”我的意思是第一种情况下，我能够每秒插入500或更多的行，但现在我只能每秒插入20行。

编辑＃3：我没有索引添加到第二个场景就像他们是在第一方案，因为指标都应该减慢插入，更新和删除，从我的理解。

编辑＃4：我保证它是完全一样的数据，因为我是一个上传。唯一的区别是，第二种情况有5个额外的列，所有文本数据类型。

编辑＃5：甚至当我除去所有的索引对场景2和左所有这些对方案1中，插入件仍然在方案2

编辑＃6慢：这两种情况都具有相同的确切的触发和功能。

编辑＃7： 我正在使用ETL工具Pentaho插入数据，因此我无法向您显示用于插入数据的代码。

我想我可能在ETL工具中有太多的转换步骤。当我尝试在与实际转换数据的步骤相同的转换中插入数据时，它的速度非常慢，但是当我简单地将已转换的数据插入空表中并将此表中的数据插入实际表格中时，使用时，插入速度比情况1快得多，每秒4000行。

场景1和场景2之间唯一的区别，除了场景2中的列增加之外，是ETL转换中的步骤数。场景2在ETL转换中具有大约20个或更多步骤。在某些情况下，还有50多个。

我想我可以通过减少转换步骤数，或将转换后的数据到一个空表，然后从该表中插入数据到我使用的是实际的表解决我的问题。

Answer 1

的PostgreSQL text和character varying是相同的，用的（可选的）长度的限制，后者的异常。他们将表现相同。

的唯一原因喜欢character varying是

• 要征收长度限制

• 要与SQL标准