我跑了两种查询，
1.故意引入查询以在大约10列中执行排序（order by）。这使用CPU，因为排序是CPU密集型操作。
该方案涉及运行查询，花费30秒并在100个不同的表上运行大约100个使用同时连接的查询.32核计算机上的CPU使用率在所有32个核心上大约为85％，并且所有100个查询并行运行。
2.在桌子上插入一百万行。
我不明白为什么会消耗CPU，因为这是纯粹的磁盘I / O.但是我使用100个同时连接/线程在单个表上插入了100万行，并且那些表上没有索引，现在插入这不是加载数据的最快方式，但重点是它在大约10个核心上耗费了大约32％的CPU时间。这比上面的要少，但我只是好奇。
我可能是错的，因为Wal存档打开并且查询日志已打开 - 这是否有助于CPU。我假设没有，因为那些也是磁盘IO。
除了postgres之外，没有其他进程/应用程序在此计算机上运行/安装。
答案 0 :(得分：2)
许多不同的事情：
如果您真的想知道多汁的细节，请启动perf并启用堆栈跟踪以查看CPU时间的花费。
答案 1 :(得分：1)
如果您的表具有主键，则它具有隐式索引。
如果表具有主键，那么它也可能存储为b树而不是简单的平面表;我不清楚这一点，因为我的postgres-fu多年来已经削弱了，但许多DBMS使用主键作为b树的默认聚类键，只是将所有内容存储在b树中。管理这个b树需要大量的CPU。
此外，如果您从100个线程和连接插入，那么postgres必须执行锁定以保持内部数据结构的一致性。争夺锁可以消耗大量的CPU，并且在具有许多CPU的机器上高效地工作尤其困难 - 获取单个互斥锁需要系统中每个CPU的协作ala缓存一致性协议。
您可能想要尝试不同数量的线程，同时测量整体运行时和CPU使用率 - 您可能会发现，例如，8个线程，使用的总CPU是当前使用量的十分之一，但仍然得到工作在原始时间的110-150％之内完成。这肯定表明锁争用正在扼杀你的CPU使用率。