使用 TEXT 数据类型时，插入、更新或删除数据是否存在某种性能差异？
我去这里发现了这个：
提示：这三种类型之间没有性能差异，除了在使用空白填充类型时增加了存储空间，以及在存储到长度受限的列时需要一些额外的 CPU 周期来检查长度。虽然 character(n) 在其他一些数据库系统中具有性能优势，但在 PostgreSQL 中没有这样的优势；事实上 character(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 多个。
我想我可以通过减少转换步骤的数量来解决我的问题，或者将转换后的数据放入一个空表中，然后将该表中的数据插入到我正在使用的实际表中。