Question

为了提高性能，我调整了参数shared_buffers和work_mem。虽然我尝试了上述参数的不同组合，但我的查询需要同时进行。当'shared_buffer'被更改时，我重新启动了服务器我的环境是

Postgres 9.1 操作系统窗口7 RAM 8GB

我尝试了1gb，2gb和3gb的shared_buffers。但查询执行时间变化非常小（以毫秒为单位）

我正在给出查询的解释计划

GroupAggregate  (cost=11100.99..12737.10 rows=50342 width=24) (actual time=181.789..268.733 rows=49829 loops=1)
  ->  Sort  (cost=11100.99..11226.84 rows=50342 width=24) (actual time=181.761..188.323 rows=50000 loops=1)    
        Sort Key: (date(t_proof_of_play.play_timestamp)), (date_trunc(''hour''::text, t_proof_of_play.play_timestamp)), t_device_endpoint.venue_hierarchy_id, t_device_endpoint.device_config_id, t_proof_of_play.asset_id
        Sort Method: quicksort  Memory: 5443kB
        ->  Hash Join  (cost=2629.37..7169.41 rows=50342 width=24) (actual time=15.416..112.175 rows=50000 loops=1)
              Hash Cond: (t_proof_of_play.device_endpoint_id = t_device_endpoint.id)
              ->  Bitmap Heap Scan on t_proof_of_play  (cost=2628.28..6224.41 rows=50342 width=20) (actual time=15.332..29.004 rows=50000 loops=1
                    Recheck Cond: ((is_processed = 0) AND (is_revenue = 1))
                    -> Bitmap Index Scan on process_revenue  (cost=0.00..2615.69 rows=50342 width=0) (actual time=15.081..15.081 rows=50000 loops=1)
                          Index Cond: ((is_processed = 0) AND (is_revenue = 1))
              ->   Hash  (cost=1.04..1.04 rows=4 width=12) (actual time=0.026..0.026 rows=4 loops=1)
                    Buckets: 1024  Batches: 1  Memory Usage: 1kB
                    ->  Seq Scan on t_device_endpoint  (cost=0.00..1.04 rows=4 width=12) (actual time=0.009..0.015 rows=4 loops=1)
Total runtime: 276.027 ms

Tabulated version on explain.depesz

欢迎提出建议。提前致谢

问候

Answer 1

正如@RichardHuxton指出的那样，你每行约5微秒检索结果。很难抱怨太多;但是这个速率证明你有很高的缓存命中率。您可能希望尝试调整连接上的成本因素以反映（使用SET命令），然后再次尝试查询以查看是否获得了更好的计划。

SET cpu_tuple_cost = 0.03;
SET random_page_cost = 1;
SET effective_cache_size = '4GB';
-- (your query here)

当然，@ regilero对shared_buffers是正确的 - 在Windows上它必须保持较小

即使是非常简单的查询，每个结果行的搜索时间也不会少于2微秒，因此对于带有连接，排序和聚合的查询，您没有足够的整个空间

Answer 2

从原始EXPLAIN中挑选出重要数据可能很困难。幸运的是，一位长期的社区成员构建了一个有用的工具来为我们制作表格 - 我添加了一个指向depesz.com的链接。

首先，我看不出更改shared_buffers会对任何特定查询产生任何影响，并且无论如何都没有提供值。改变机器上内存使用的总体平衡是一个普遍的价值。您可以根据总体工作负载而不是特定查询来调整它。

查询的三个主要部分是连接，排序和聚合。这似乎是合理的。

我不知道你正在运行什么聚合（你没有给出查询）。大概你在play_timestamp上总结了一天/小时（基于排序）。你需要两个级别吗？

对于相当详细的排序（5列，两列基于函数调用），只要work_mem足够大，就可以进行排序，那里没什么可做的。

所以 - 我们或许可以改善联接。部分索引可能有所帮助。类似的东西：

CREATE INDEX idx1 ON t_proof_of_play (device_endpoint_id) WHERE is_processed=0 AND is_revenue=1

当然，没有任何内容是免费的，只要您更新t_proof_of_play，就会支付此索引的维护费用。

即使这样，如果你将加入时间减半，只会将总时间从276ms缩短到235ms左右。你在大约0.25秒内处理了50,000行 - 每行5微秒。

Answer 3

补充@Richard Huxton回答。

在Windows上stated in the documentation，您无法使用大量 shared_buffers ：

此外，在Windows上，shared_buffers的大值不是那么有效。您可能会发现更好的结果，保持设置相对较低，而更多地使用操作系统缓存。 Windows系统上shared_buffers的有用范围通常为64MB到512MB。

因此，您应该将此参数设置为512MB，PostgreSQL将无法在Windows上使用更多共享内存来优化其内存使用量。在我看来，Windows并不是PostgreSQL服务器的最佳操作系统，无论如何你也可以尝试将effective_cache_size调整到50％或75％的可用内存（所以可能是2或4GB）。这是PostgreSQL的一个提示，告诉它操作系统肯定会使用可用的RAM来存储最近使用的文件。这样，您的查询优化器可能会认为访问磁盘数据的成本并不像通常想象的那么高。

postgres 9.1性能参数

3 个答案: