【问题标题】:Optimization postgresql request优化postgresql请求
【发布时间】:2021-09-05 08:34:03
【问题描述】:

如何在 postgresql 中优化请求? 我应该创建哪些最佳索引?

我尝试为 t_my.id、t_my.param1、t_my.param2、t_my_other.param3 添加单独的索引,但我的请求工作缓慢。 或者我可以进行一些更改或使用其他一些函数来获取网格结果数组?

大小 t_my 50000 行

大小 t_my_other 相同 50000 行

我需要为 Serie1 和 Serie2 的每个组合获取值网格

金额,总和,Serie1,Serie2

EXPLAIN
WITH CTS AS
(
    SELECT * FROM (SELECT 50.0+10.0/11*generate_series(0, 11) as Serie) as tempt CROSS JOIN (SELECT 20.0+25.0/11*generate_series(0, 11) as Serie2) as t
) 

SELECT    COUNT(id) AS amount, SUM(param3) AS wire_guard, CTS.Serie, CTS.Serie2
FROM      CTS 
LEFT JOIN (SELECT t_my.id,t_my.param1,t_my.param2, t_my_other.param3 FROM t_my 
          LEFT JOIN t_my_other ON t_my.id = t_my_other.id_object) as objects 
ON        objects.param1>= CTS.Serie 
AND       objects.param1<  CTS.Serie + (60.0-50)/11
AND       objects.param2>=  CTS.Serie2
AND       objects.param2<  CTS.Serie2 + (35.0-10)/11

GROUP BY  (CTS.Serie, CTS.Serie2)
ORDER BY  CTS.Serie
;
;```

plan
'GroupAggregate  (cost=1617712999.78..1649282408.93 rows=40000 width=80)'
'  Group Key: cts.serie, cts.serie2'
'  CTE cts'
'    ->  Nested Loop  (cost=0.00..12532.53 rows=1000000 width=64)'
'          ->  Result  (cost=0.00..5.01 rows=1000 width=32)'
'          ->  Materialize  (cost=0.00..20.02 rows=1000 width=32)'
'                ->  Result  (cost=0.00..5.01 rows=1000 width=32)'
'  ->  Sort  (cost=1617700467.25..1624014269.08 rows=2525520732 width=76)'
'        Sort Key: cts.serie, cts.serie2'
'        ->  Hash Right Join  (cost=604227963.92..662200918.76 rows=2525520732 width=76)'
'              Hash Cond: (t_my_other.id_object = t_my.id)'
'              ->  Seq Scan on t_my_other (cost=0.00..8501.18 rows=297518 width=12)'
'              ->  Hash  (cost=546125388.00..546125388.00 rows=2399074074 width=72)'
'                    ->  Nested Loop Left Join  (cost=434.15..546125388.00 rows=2399074074 width=72)'
'                          ->  CTE Scan on cts  (cost=0.00..20000.00 rows=1000000 width=64)'
'                          ->  Bitmap Heap Scan on t_my  (cost=434.15..522.12 rows=2399 width=24)'
'                                Recheck Cond: ((param2 >= (cts.serie2)::double precision) AND (param2 < ((cts.serie2 + 2.2727272727272727))::double precision) AND (param1 >= (cts.serie)::double precision) AND (param1 < ((cts.serie + 0.90909090909090909091))::double precision))'
'                                ->  BitmapAnd  (cost=434.15..434.15 rows=2399 width=0)'
'                                      ->  Bitmap Index Scan on i_param2  (cost=0.00..216.35 rows=21592 width=0)'
'                                            Index Cond: ((param2  >= (cts.serie2)::double precision) AND (param2  < ((cts.serie2 + 2.2727272727272727))::double precision))'
'                                      ->  Bitmap Index Scan on i_param1  (cost=0.00..216.35 rows=21592 width=0)'
'                                            Index Cond: ((param1 >= (cts.serie)::double precision) AND (param1  < ((cts.serie + 0.90909090909090909091))::double precision))'

【问题讨论】:

  • 编辑您的问题并提供示例数据、期望的结果、表的大小、当前的执行计划以及代码应该做什么的解释。
  • 这不可能是您实际运行的查询,我可以看到其中至少有一个语法错误... (ON .. AND ... ON ... AND ...) 以及CTS.Serie需要CTS.Serie1。请按照 Gordon 的评论,显示速度较慢的 ACTUAL 查询以及解释计划等。
  • 这就是 generate_series() 的问题:它还生成 estimated 行数=1000,cathesian 乘积将其放大到 1M。顺便说一句:你的 Postgres 版本是什么? [简短修复:摆脱 CTE] 并且:EXPLAIN ANALYZE 请...

标签: sql postgresql optimization indexing generate-series


【解决方案1】:

升级到 PostgreSQL v12 或更高版本,因为

  1. 该版本引入了优化器支持函数,允许正确估计 generate_series 的行数

  2. 从 v12 开始,CTE 不再充当优化障碍

这应该会改进执行计划,从而提高性能。

【讨论】:

    猜你喜欢
    • 2015-08-02
    • 2019-02-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-02-17
    • 2018-08-01
    • 2017-10-24
    • 2016-03-18
    相关资源
    最近更新 更多