根据对此问题的评论，我询问了 PostgreSQL 9.2 中的空闲连接，一些未提交的事务（可能与其中一些空闲连接有关）可能会导致一些性能问题。
确定是否存在未提交事务的好方法是什么（如果有办法知道它们所在的连接是否空闲，则可以加分）？
非常感谢！
我的数据库服务器上的一些查询似乎需要很长时间才能响应，而且我认为 CPU 使用率很高。运行时ps aux，我看到约 250 个“空闲”连接（我认为这太多了）。我还没有开始做一个完整的诊断，但我想知道这是否是一个开始寻找的好地方。
我还在使用 PgBouncer 和事务级池。我怀疑我可以idle通过调整池大小轻松减少连接数。但是，除非有充分的理由，否则我不想开始进行太多更改。
idlePostgreSQL 9.2 中的许多连接会影响性能吗？
非常感谢！
假设列idx_int上有一个索引int_col，这样的查询的算法复杂度是多少？
SELECT id FROM table
WHERE table.int_col > 1;
我特别想知道查询是否比执行相等子句效率低得多（如果我理解正确的话是 O(log N)）。我很确定它们都可以使用 B 树，所以我希望它们在复杂性/效率方面大致相同。
非常感谢！
需要知道 PostgreSQL 如何对磁盘上的记录进行排序。在这种情况下，我想利用文档中所述的索引组合，据我所知，它使用位图来获取匹配的行并根据它们的物理位置返回它们。有问题的表已按其主键聚集。
据我了解，PostgreSQL 在集群完成后不会自动继续进行集群（尽管它确实记得它是根据某个索引进行集群的）。现在，由于这是主键，我想知道物理存储顺序是否会根据这个顺序（如果是真的，我想利用我们的优势进行特定查询）。
总之，PostgreSQL 如何对其新记录进行排序，尤其是在集群之后？
非常感谢！
试图弄清楚我应该如何期望我的数据库执行。基本上，我需要确定我设置的服务器何时达到其性能极限——这将帮助我更好地规划服务器扩展。
这个问题更多地针对我可以计算或估计（真的，任何想法都会很好）预期性能的方式。理想情况下，这应该可以帮助我想出一个可以基于多个因素（如记录大小、行数等）运行的公式，而不是基于特定服务器/数据库的主观假设。
那么，确定 PostgreSQL 服务器预期性能的好方法是什么？
非常感谢！
使用 SQLAlchemy 查询 PgBouncer 后面的 PostgreSQL 数据库，使用事务级池。
用于这种设置的最佳模式是什么？我应该使用一个每个进程ConnectionPool一个引擎，还是应该为每个请求创建一个引擎，并NullPool为它们中的每一个使用？我应该使用完全不同的模式吗？
非常感谢！让我知道是否需要更多信息，我会尽快更新。
我们在 Rackspace 中创建了一个数据库服务器的映像。然后，我们使用该图像创建了一个新服务器，期望一切正常。但是，我们看到的索引性能似乎很差，甚至查询计划在比较explain analyze第一台服务器和第二台服务器的输出时也不同。基本上，第二台服务器——从保存的图像恢复的服务器——似乎并不像它应该的那样依赖索引。
是否有与图像恢复相关的内容会导致此行为？如果是这样，可能需要做些什么来解决这个问题？我应该看看别的地方吗？
非常感谢！如果需要，我可以提供更多信息，所以请告诉我这是否有用。
如果我设置了一个包含多个数据库条目的 pgbouncer.ini 配置文件，那么 pgBouncer 是否会为每个条目创建一个单独的池？我会这么认为，但无法证实这一点。
例如，像这样：
[数据库] db1 = ... db2 = ... [pgbouncer] . . . max_client_conn = 480 default_pool_size = 250
我会为每个数据库设置一个 250 个默认池，最多 480 个，还是在两者之间共享总共250 个默认连接和最多 480 个连接？
非常感谢！
使用 PostgreSQL，我们有数百个并发进程执行常规数据库访问。我们的数据分布在几个数据库服务器中，每个数据库服务器都包含一个带有 PgBouncer 的连接池。问题是所有服务器上的 RAM 使用率（通过top- 不确定这是否是确定这一点的最佳方法）往往会攀升至接近或 100%。我很确定这很糟糕。
我已经尝试了 pgbouncer / postgres 的几种配置，最终（在我的系统运行几分钟后）RAM 使用率上升到这一点。
我的问题是：
- 我应该在与数据库不同的服务器上设置我的连接池吗？似乎同一台服务器上有太多打开的连接可能会导致这种情况。
- 一般来说，在 Postgres 上使用 RAM 有什么好的指导方针？我真的不知道如何判断服务器是否表现良好/符合预期或表现不佳。
非常感谢！如果需要更多信息，请告诉我，我会尽快发布。
编辑： 当运行 vmstat 1 一段时间时，我得到这个：
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu ----- rb swpd 免费 buff 缓存 si so bi bo in cs us sy id wa st 0 34 241048 20124 10208 2636248 340 80 1820 2968 3846 2864 12 14 0 73 1 0 56 240980 19256 10224 2636860 360 140 2568 6100 5773 4874 13 20 0 66 1 0 56 240916 19876 10244 2635528 476 188 3760 3740 7347 5898 21 27 0 52 1 1 32 240896 19512 10260 2635532 448 240 3192 4720 5426 4295 15 21 1 63 1 1 72 240844 19884 10280 2633332 728 216 3620 4424 7867 6927 16 27 0 56 1 1 62 240568 19884 10292 2633640 404 0 3780 3176 6546 5376 16 21 0 62 1 2 42 240348 31044 10296 2623100 460 0 2844 3992 6215 5181 19 20 0 60 1 0 55 240116 20628 10304 2633396 360 0 3288 4264 6749 5958 15 26 0 59 1 0 71 239896 19884 10300 2632892 624 56 3804 4780 6682 6191 14 22 0 64 1 2 59 239660 19016 10304 2633980 380 4 3324 3524 6429 5233 15 22 0 63 1 3 49 239540 27572 10312 2625460 280 92 2820 2764 5424 4533 13 19 0 66 1 1 58 239272 19264 10316 2632580 676 0 3844 3512 7558 6122 17 27 0 55 1 1 51 239116 41816 10312 2609204 316 48 3156 3352 5730 4689 16 22 0 62 1 2 60 238804 74420 10288 2577096 596 0 3296 3880 7080 5153 17 27 0 55 1 3 64 237500 93516 10272 2562168 372 0 3296 2964 6878 5568 16 30 0 54 1 0 39 237308 106660 10288 2548092 284 0 1140 3772 4477 3615 10 16 0 74 1 2 60 237052 119680 10288 2534584 596 0 2956 4688 6976 5747 22 27 0 51 1 1 70 236772 118440 10284 2530824 532 0 2956 3744 7991 6406 20 34 0 45 1 0 76 236464 123136 10292 2525108 564 0 2940 4564 6940 6000 16 28 0 56 1 1 67 236212 139520 10296 2508848 328 0 2896 2660 5471 4493 15 21 0 64 1 0 36 235960 151796 10244 2495876 584 48 2392 3824 5744 4380 13 24 0 61 1 1 65 235700 141264 10240 2506308 432 0 2564 5412 6870 6069 16 25 4 55 1 0 51 235352 135560 10240 2512036 324 0 2836 3620 7448 6674 20 25 0 54 1 2 71 235180 130352 10228 2517284 292 0 2236 5276 6477 5511 14 24 0 62 1 3 74 234880 127624 10228 2519252 528 0 2704 4268 7159 6017 15 26 0 59 1 1 49 234668 126632 10216 2519648 400 0 2440 3860 4797 4144 13 16 0 70 1 2 51 234436 147588 10204 2499160 296 0 1896 3664 5565 4449 15 20 0 65 0 1 56 234244 142132 10196 2504652 244 0 2320 4628 5162 4641 13 20 0 66 1 2 64 234068 138908 10200 2507900 352 0 2276 3960 6161 5640 14 20 0 65 1 2 69 233844 134336 10200 2512368 332 0 1872 3792 5404 4720 12 18 0 70 1 0 51 233564 130492 10200 2516328 236 0 2068 3860 4780 4345 10 18 0 71 1 2 66 233328 124912 10204 2521172 364 0 2480 4532 6694 6401 13 23 0 63 1 1 53 233068 118340 10212 2526236 252 0 2652 2972 6548 5481 18 28 0 54 1 1 66 232852 112388 10216 2531388 352 0 2592 4656 7537 6520 25 26 0 49 1 1 27 232628 126772 10220 2517960 252 0 2332 3344 3670 2787 9 11 0 78 1 3 74 232376 119208 10236 2524356 500 0 3024 5568 9162 7131 21 33 0 45 1 0 29 232192 113876 10236 2529992 280 0 2180 5976 4703 3668 12 14 0 73 1 2 81 231912 108296 10244 2535604 496 0 2864 4532 7717 6603 19 24 0 57 1 1 55 230600 107304 10260 2540572 400 0 2780 3908 6542 5568 15 26 0 58 1 2 54 230356 101972 10268 2545692 220 0 2224 6044 5942 5082 15 23 0 62 1 2 47 230044 113504 10272 2534088 180 0 2620 5820 7214 6138 16 23 0 61 1 0 24 229872 110280 10272 2537612 152 0 2000 5312 3610 2813 8 12 0 79 1 3 30 229816 106684 10276 2541068 24 0 1116 5880 4148 2923 12 15 0 73 1 0 67 229536 100484 10276 2546612 260 0 3084 3656 7847 7088 20 28 0 51 1 0 50 229240 95152 10280 2552164 388 0 2648 4432 6670 5479 17 22 0 61 1 2 52 229060 89944 10288 2557044 268 0 2388 3780 5916 5029 22 22 0 55 1 2 55 228828 85604 10292 2561036 252 0 2032 3152 6003 5416 16 20 0 64 1 1 67 228632 81016 10292 2565560 164 0 2472 3896 5842 5113 15 21 0 64 1 0 29 228420 77792 10296 2568708 264 0 2588 3496 4775 3954 10 18 0 71 1 0 13 228340 77048 10296 2569728 60 0 1000 15576 1620 676 3 4 0 93 1 3 31 228276 75064 10300 2570736 44 0 928 7840 3764 2959 12 12 0 75 1 4 56 227976 72212 10300 2573832 368 0 2976 3880 6327 5287 20 23 0 56 1 2 52 227700 69236 10300 2576308 256 0 2336 4128 7586 5988 17 27 0 55 1 0 38 227452 66508 10304 2579332 240 0 2916 3400 5230 4456 14 18 0 68 1
在我们的 Python 应用程序上看到查询性能并不令人满意，该应用程序运行多个SQLAlchemy core用于访问 PostgreSQL 9.2 数据库的进程。我们可能有大约 100 到 200 个或更多并发进程对数据库执行查询。
我们没有类似pgpoolII或pgbounce当前安装的连接池系统。
我已经测试了一个查询，它可以从我们的应用程序中花费大约1-10 秒的时间，当运行结束时最多psql需要20 毫秒。
我们认为这个问题与并发连接有关，特别是因为上述行为以及我们在访问系统中的不同表时看到这些性能下降。但是，我们不确定这一点，并且可以很容易地接受其他建议或解决方案。
处理来自多个进程对单个数据库服务器的并发连接的通常方法是什么，以使查询能够快速执行？