使用TEXT数据类型时，插入，更新或删除数据会有某种性能差异吗？
我去here找到了这个：
提示：除此之外，这三种类型之间没有性能差异 使用空白填充类型时增加的存储空间，和 存储到a时，检查长度的额外CPU周期很少 长度受限的列。虽然字符（n）具有性能 在其他一些数据库系统中的优势，没有这样的优势 在PostgreSQL中;事实上，字符（n）通常是最慢的 三，因为它额外的存储成本。在大多数情况下文字 或者应该使用变化的字符。
这让我相信应该没有性能差异，但是我的朋友，比我更有经验，说TEXT数据类型的插入，更新和删除速度较慢。
我有一个用触发器和函数分区的表，并且索引非常严格，但插入的速度并不那么慢。
现在我有另一个表，还有5个列，所有列都是文本数据类型，相同的触发器和函数，没有索引，但插入速度非常慢。
根据我的经验，我认为他是正确的，但你们有什么想法？
编辑＃1： 我正在上传相同的确切数据，只是第二个版本还有5个列。
编辑＃2： 通过＆＃34;慢＆＃34;我的意思是在第一个场景中，我能够每秒插入500行或更多行，但现在我每秒只能插入20行。
编辑＃3：我没有将索引添加到第二个场景，就像它们在第一个场景中一样，因为根据我的理解，索引应该减慢插入，更新和删除的速度。
编辑＃4：我保证它是完全相同的数据，因为我是上传它的人。唯一的区别是，第二个场景有5个附加列，所有文本数据类型。
编辑＃5：即使我删除了场景2中的所有索引并将所有索引都保留在场景1中，场景2中的插入仍然较慢。
编辑＃6：两种情况都具有相同的触发和功能。
编辑＃7： 我正在使用ETL工具Pentaho来插入数据，所以我无法向您展示用于插入数据的代码。
我想我可能在ETL工具中有太多的转换步骤。当我尝试在与实际转换数据的步骤相同的转换中插入数据时，它非常慢，但是当我简单地插入已经转换为空表的数据然后将此表中的数据插入到实际表中时我＃＆＃ 39; m使用，插入比方案1快4000行每秒。
方案1和方案2之间的唯一区别（方案2中列的增加除外）是ETL转换中的步骤数。方案二在ETL转换中有大约20个或更多步骤。在某些情况下，还有50多个。
我认为我可以通过减少转换步骤的数量，或者将转换后的数据放入空表，然后将此表中的数据插入到我使用的实际表中来解决我的问题。
答案 0 :(得分：1)
PostgreSQL text和character varying是相同的，但后者的（可选）长度限制除外。它们的表现相同。
选择character varying的唯一理由是
您想要施加长度限制
您希望符合SQL标准