postgresql - postgres 9.1 性能参数

Question

为了提高性能，我调整了参数 shared_buffers 和 work_mem。虽然我尝试了上述参数的不同组合，但我的查询花费了相同的时间。每当更改“shared_buffer”时，我都会重新启动服务器我的环境是

Postgres 9.1操作系统 Windows 7内存 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 微秒的速度检索结果。很难对此提示太多。但是这个比率证明你有一个非常高的缓存命中率。您可能想尝试调整连接的成本因素以反射(reflect)这一点(使用 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 微秒，因此对于具有连接、排序和聚合的查询，您没有整体很大的改进空间.