我有一个 Postgres 表，其中包含大量索引列（总共大约 100 列）。任何行更新都会导致所有索引更新，这对数据库引擎来说是一项繁重的工作。
我认为基于此文档页面，索引更新时读取不会被阻止，但由于行写入是原子的，我假设在其结果集中包含锁定行的读取将导致读取被阻止。这是正确的吗？
我还认为上面的页面是说多行更新可以并发进行，因为一次只有一行被锁定以进行索引更新，并且 btree 索引能够处理并发更新。它是否正确？即更新不会互相阻塞，除非它们试图更新同一行？
如果索引更新降低了读取或写入吞吐量，即使没有行冲突，那么有没有办法告诉 Postgres 可以一次更新一个表的索引，而不是原子地更新所有索引，以便读取查询该表不会因为索引被锁定而减慢速度吗？我可以接受以更高并发的名义缺乏一致性。
基本上我想了解具有如此多索引列以及许多并发读取器和写入器的更新操作的读取和写入并发影响。我还想知道是否有一种方法可以调整 Postgres 来权衡查询吞吐量（读和写）的一致性。
你有两个问题...一个可能与你的数据模型有关，另一个与 PostGreSQL 的有限架构有关。
1 - 数据模型
一张有100个索引的表，至少需要100列，甚至更多……对于关系型数据库来说，规范化理论允许关系型数据库整形，导致很多表的列数很少。 如果有几十列，您可能不再处于关系型（OLTP）状态，而可能处于决策型（OLAP）状态或出现严重的建模错误
1.1 - OLAP 案例
在这种情况下，有必要求助于专门用于 OLAP 数据存储的数据库，这可以是昂贵的 Tarradata 或 Microsoft SQL Server 的 SSAS 部分。
这些引擎能够压缩、去重、预计算和自动索引此类数据结构，以最大限度地提高数据采集和恢复的速度。
PotsGreSQL 根本不是为此而设计的...
1.2 - 数据模型
如果您的数据模型不遵循为减少 IO 而开发的规范形式，那么您必须通过根据列数将它们分成更小的表来纠正表的结构。在这种情况下，更新会轻得多，因为索引的数量会少得多！
就我而言，从事数据库审计30年，任何超过20列的表在我眼中都是可疑的，当我对数据库建模时，我尽量不超过10列（除了PK和可能的FK）。
2 - PostGreSQL 的结构
PostGreSQL 的开发建立在基于进程而不是线程的模型上...这意味着 PostGreSQL 中的并行性非常有限且昂贵...请参阅以下差异： https://www.guru99.com/difference- Between-process-and-thread.html 特别是，PostGreSQL 会顺序更新索引和表行，而其他 RDBMS 会并行执行此操作...
在 Microsoft SQL Server 等其他数据库系统中，自动并行运行，从而大大缩短读取和写入响应时间...
阅读我不久前就这个主题所做的比较基准测试...... 流程维护 查询次数
PostGreSQL 工作人员正在考虑修改引擎架构以转向线程模型，但我担心我们将不得不等待很多年才能完成......
PG 架构中的另一个问题是，由于 MVCC，每个 UPDATE 都会复合一个新行，相当于 INSERT + DELETE...这是最坏的情况...
结论
除了危险的UNLOGGED模式之外，还有三种解决方案可供您选择...等待这个基于线程的PostGreSQL新版本，修改您的表结构或更改RDBMS！
PS：另一种解决方案是使用像 MS SQL Server 那样的“内存”数据库...