检查PostgreSQL在执行大容量插入时自动创建现有索引所需的时间，使用“从火花复制”命令
我正在做一个大容量插入从火花到postgres表。我摄入的数据量是巨大的。记录的数目约为1.2亿至1.3亿。
我首先将记录保存为分布式存储位置上的多个csv文件，即用例中的S3桶。现在，我使用多个copy命令复制PostgreSQL表中的数据。实际的PostgreSQL表有四个索引。
复制命令大约需要8小时才能保存数据。我在没有索引的情况下创建了一个类似的表，数据在28到30分钟内保存下来。基于我在多个网站上进行的搜索，他们提到索引会降低性能，这肯定是基于我上面指定的时间差。
现在的实际问题是，我如何能够识别哪个索引创建需要更多的时间。是否有任何实用工具、查询或命令显示在执行大容量插入时在表上创建索引所需的时间。我使用下面的查询来查看PostgreSQL实例上正在运行的多个复制命令的数量：
SELECT * FROM pg_stat_activity
where usename = 'xyz' and application_name ='PostgreSQL JDBC Driver'是否有类似于此查询或任何工具或命令，我可以使用这些工具或命令来查看创建索引所需的时间t。另外，每个索引所花费的时间是多少？
欢迎任何想法、指导或建议。我对PostgresQL不太熟悉。
回答 2
Database Administration用户
发布于 2021-01-21 15:03:30
只要所有索引都是B-树索引，修改它们的时间应该大致相同。
当然，具有昂贵表达式的索引将花费更长的时间，而在具有昂贵排序规则的字符串列上则需要更长的索引。
您可以比较填充表上的CREATE INDEX语句的持续时间--如果一个索引构建的时间是另一个索引的两倍，那么修改它可能也需要大约两倍的时间。
如果新加载的数据量很大，则删除和重新创建索引可能会更快。你得做实验。
Database Administration用户
发布于 2021-01-21 17:32:53
一个术语问题:已经存在的索引在添加新行时不会“创建”，而是得到“维护”。使用正确的术语可能会使互联网搜索更加成功。
PostgreSQL不提供用于此操作的工具。人们可能认为pg_stat_user_indexes应该有blk_read_time和blk_write_time的列，但它没有它们。我不知道这是否有原因，或者这仅仅是track_io_timing实现时的疏忽。解释(分析，缓冲区)也不打破块定时的基础关系，以区分一个表和它的索引。
在没有这些数据的情况下，您最好的选择可能是做一个实验，依次删除每个索引的所有(除了一个)索引，并将数据加载到一个已经很大的表中，看看需要多长时间。
一旦索引变得非常大，限制通常将是读取索引页页，这样它就可以为新的元组更新它。这通常是随机IO，所以会很慢。如果所添加的行已经按照任何索引中使用的顺序排序(或者至少是“集群”)，则该索引将花费更少的时间来维护，因为IO模式对它的随机性较小。一个类似的效果是，如果所有索引都足够小，足以适应RAM (但不适合shared_buffers)，那么您可能不需要从磁盘中读取每个叶块，因为它已经在缓存中，但是您仍然必须将每个叶块写回磁盘。操作系统可以缓冲这些写入，但是它通常不愿意缓冲干净的页面(用于读取)，因此在从随机块写入悬崖掉下来之前(就索引大小而言)，您会从随机块读取悬崖上掉下来。
https://dba.stackexchange.com/questions/283709
复制相似问题
腾讯云开发者
