我可以从简单查询中获得什么性能：简单示例很慢答案

【问题标题】：What performance can I expect from a simple query: Simple example is slow我可以从简单查询中获得什么性能：简单示例很慢
【发布时间】：2021-05-16 20:38:34
【问题描述】：

我正在使用由外部公司托管的 PostgreSQL 数据库。查询比我预期的要慢得多，我需要帮助才能理解。

案例：我有一个表，例如 MainTable，大约有 15.000.000 行。该表有 7 列类型：

（整数、整数、整数、日期时间、日期时间、日期时间、浮点数）。

主键由前两个整数列组成，分别称为 GroupId 和 ValueId。我经常需要从一个组中提取所有数据。例如：

SELECT * FROM MainTable WHERE GroupId = 23.

MainTable 中大约有 50 个组，每个组包含大约 15000000/50 = 300,000 个条目。

我担心上面的选择查询大约需要 4-5 秒：

这真的是预期的性能吗？
如果没有，您对如何改进查询有什么建议吗？我已经在 GroupID 上尝试过表索引。
我能否计算出预期性能的上限，以了解我离最优状态还有多远？

我对 SQL 服务器的唯一了解是它有 2GB 内存。

这是执行计划（在 GroupID 上有一个简单的索引）：

Gather  (cost=5897.44..260656.04 rows=261275 width=44) (actual time=33.456..126.031 rows=227646 loops=1)
  Workers Planned: 2
  Workers Launched: 2
  Buffers: shared hit=2755
  ->  Parallel Bitmap Heap Scan on data  (cost=4897.44..233528.54 rows=108865 width=44) (actual time=11.099..34.584 rows=75882 loops=3)
        Recheck Cond: (group_id = 915)
        Heap Blocks: exact=492
        Buffers: shared hit=2755
        ->  Bitmap Index Scan on idx  (cost=0.00..4832.12 rows=261275 width=0) (actual time=32.792..32.793 rows=227646 loops=1)
              Index Cond: (group_id = 915)
              Buffers: shared hit=626
Planning Time: 0.064 ms
JIT:
  Functions: 6
  Options: Inlining false, Optimization false, Expressions true, Deforming true"
  Timing: Generation 0.851 ms, Inlining 0.000 ms, Optimization 0.000 ms, Emission 0.000 ms, Total 0.851 ms
Execution Time: 145.180 ms

【问题讨论】：

性能可能不是由数据库本身驱动，而是由序列化/传输/反序列化结果驱动。对我来说，您尝试在该查询中转储 300k 行似乎有问题。也许想想你背后的业务逻辑。
请edit您的问题并添加使用explain (analyze, buffers, format text)生成的execution plan（不是只是一个“简单”解释）为formatted text，并确保保留计划的缩进。粘贴文本，然后将``` 放在计划前一行和计划后一行。还请包括所有索引的完整 create index 语句。
@a_horse_with_no_name：我已经添加了执行计划。这有帮助吗？
以及服务器和客户端之间是什么样的网络
您的查询只需要 145 毫秒秒。（0.15 秒）。因此，您所经历的 5 秒是将 227646 行从数据库服务器发送到您的应用程序（或 SQL 客户端）并在那里处理这些行所需的时间。数据库不是瓶颈。您是否有机会使用 pgAdmin？众所周知，在显示数据时会非常慢——尤其是像这样的大型结果。

标签： python postgresql query-optimization

【解决方案1】：

是的，这是非常不错的性能，因为您选择了 227646 行。你很幸运相关性很高（所有行都粘在一个相对较少的 8kB 块中）并且所有内容都被缓存了，否则性能会更差。

【讨论】：