postgres的generate_series性能上服務器慢然後膝上型

Question

我有一系列的觀點，即建立過彼此的是這樣的：

rpt_scn_appl_target_v - > rpt_scn_appl_target_unnest_v - > rpt_scn_appl_target_unnest_timeseries_v - > rpt_scn_appl_target_unnest_timeseries_ftprnt_v

在該視圖中..rpt_scn_appl_target_unnest_timeseries_v，我使用generate_series函數在1/1/2015和12/31/2019之間生成每月行。

什麼我注意到的是：

this one takes 10secs to run 
select * from rpt_scn_appl_target_unnest_timeseries_ftprnt_v where scenario_id = 202 

this one takes 9 secs to run: 
select * from rpt_scn_appl_target_unnest_timeseries_v where scenario_id = 202 

this one takes 219msecs to run: 
select * from rpt_scn_appl_target_unnest_v where scenario_id = 202 

this one takes <1sec to run: 
select * from rpt_scn_appl_target_v where scenario_id = 202 

我注意到註釋掉在視圖中generate_series代碼，查詢運行在一秒之內，但有了它，它需要10secs運行...

rpt_scn_appl_target_unnest_timeseries_v查看：

CREATE OR REPLACE VIEW public.rpt_scn_appl_target_unnest_timeseries_v AS 
SELECT a.scenario_id, 
    a.scenario_desc, 
    a.scenario_status, 
    a.scn_appl_lob_ownr_nm, 
    a.scn_appl_sub_lob_ownr_nm, 
    a.scenario_asv_id, 
    a.appl_ci_id, 
    a.appl_ci_nm, 
    a.appl_ci_comm_nm, 
    a.appl_lob_ownr_nm, 
    a.appl_sub_lob_ownr_nm, 
    a.cost, 
    a.agg_complexity, 
    a.srvc_lvl, 
    a.dc_loc, 
    a.start_dt, 
    a.end_dt, 
    a.decomm_dt, 
    a.asv_target_id, 
    a.asv_target_desc, 
    a.asv_target_master, 
    a.prod_qty_main_cloud, 
    a.prod_cost_main_cloud, 
    a.non_prod_qty_main_cloud, 
    a.non_prod_cost_main_cloud, 
    a.prod_qty_main_onprem, 
    a.prod_cost_main_onprem, 
    a.non_prod_qty_main_onprem, 
    a.non_prod_cost_main_onprem, 
    a.prod_qty_target_onprem, 
    a.prod_cost_target_onprem, 
    a.non_prod_qty_target_onprem, 
    a.non_prod_cost_target_onprem, 
    a.prod_qty_target_cloud, 
    a.prod_cost_target_cloud, 
    a.non_prod_qty_target_cloud, 
    a.non_prod_cost_target_cloud, 
    a.type, 
    a.cost_main, 
    a.qty_main, 
    a.cost_target, 
    a.qty_target, 
    a.dt, 
    a.mth_dt, 
     CASE 
      WHEN a.type ~~ '%onprem%'::text THEN 'On-Prem'::text 
      ELSE 'Cloud'::text 
     END AS env_stat, 
     CASE 
      WHEN a.type ~~ '%non_prod%'::text THEN 'Non-Prod'::text 
      ELSE 'Prod'::text 
     END AS env, 
     CASE 
      WHEN a.dt <= a.decomm_dt THEN COALESCE(a.cost_main, 0::double precision) 
      WHEN a.decomm_dt IS NULL AND a.end_dt IS NULL AND a.start_dt IS NULL THEN a.cost_main 
      ELSE 0::double precision 
     END AS cost_curr, 
     CASE 
      WHEN a.dt <= a.decomm_dt THEN COALESCE(a.qty_main, 0::bigint) 
      WHEN a.decomm_dt IS NULL AND a.end_dt IS NULL AND a.start_dt IS NULL THEN a.qty_main 
      ELSE 0::bigint 
     END AS qty_curr, 
     CASE 
      WHEN a.dt < a.start_dt THEN 0::bigint 
      WHEN a.dt >= a.start_dt AND a.dt < a.end_dt AND a.type ~~ '%non_prod%'::text THEN COALESCE(a.qty_target, 0::bigint) 
      WHEN a.dt > a.end_dt THEN COALESCE(a.qty_target, 0::bigint) 
      ELSE 0::bigint 
     END AS qty_trgt, 
     CASE 
      WHEN a.dt < a.start_dt THEN 0::double precision 
      WHEN a.dt >= a.start_dt AND a.dt < a.end_dt AND a.type ~~ '%non_prod%'::text THEN COALESCE(a.cost_target, 0::double precision) 
      WHEN a.dt > a.end_dt THEN COALESCE(a.cost_target, 0::double precision) 
      ELSE 0::double precision 
     END AS cost_trgt 
    FROM (SELECT t1.scenario_id, 
      t1.scenario_desc, 
      t1.scenario_status, 
      t1.scn_appl_lob_ownr_nm, 
      t1.scn_appl_sub_lob_ownr_nm, 
      t1.scenario_asv_id, 
      t1.appl_ci_id, 
      t1.appl_ci_nm, 
      t1.appl_ci_comm_nm, 
      t1.appl_lob_ownr_nm, 
      t1.appl_sub_lob_ownr_nm, 
      t1.cost, 
      t1.agg_complexity, 
      t1.srvc_lvl, 
      t1.dc_loc, 
      t1.start_dt, 
      t1.end_dt, 
      t1.decomm_dt, 
      t1.asv_target_id, 
      t1.asv_target_desc, 
      t1.asv_target_master, 
      t1.prod_qty_main_cloud, 
      t1.prod_cost_main_cloud, 
      t1.non_prod_qty_main_cloud, 
      t1.non_prod_cost_main_cloud, 
      t1.prod_qty_main_onprem, 
      t1.prod_cost_main_onprem, 
      t1.non_prod_qty_main_onprem, 
      t1.non_prod_cost_main_onprem, 
      t1.prod_qty_target_onprem, 
      t1.prod_cost_target_onprem, 
      t1.non_prod_qty_target_onprem, 
      t1.non_prod_cost_target_onprem, 
      t1.prod_qty_target_cloud, 
      t1.prod_cost_target_cloud, 
      t1.non_prod_qty_target_cloud, 
      t1.non_prod_cost_target_cloud, 
      t1.type, 
      t1.cost_main, 
      t1.qty_main, 
      t1.cost_target, 
      t1.qty_target, 
      generate_series('2015-01-01 00:00:00'::timestamp without time zone, '2019-12-31 00:00:00'::timestamp without time zone, '1 mon'::interval)::date AS dt, 
      to_char(generate_series('2015-01-01 00:00:00'::timestamp without time zone, '2019-12-31 00:00:00'::timestamp without time zone, '1 mon'::interval)::date::timestamp with time zone, 'YYYY-MM'::text) AS mth_dt 
      FROM rpt_scn_appl_target_unnest_v t1) a; 

什麼我也注意到也就是我的筆記本電腦和AWS數據庫之間的性能具有相同數據，表格和視圖的rds服務器在我的筆記本電腦上運行得更快，儘管它的內存和CPU更少。我在筆記本電腦上運行postgres 9.6，在AWS rds上運行9.6。我的筆記本電腦是MacBook Pro與16GB的內存和I7雙核心。對於rds，我使用的是一個m4.4xlarge，它是16個內核和64gb的內存。

這裏是AWS解釋計劃： https://explain.depesz.com/s/UGF

我的筆記本電腦解釋計劃： https://explain.depesz.com/s/zaWt

所以我想我的問題是：

1）爲什麼查詢需要更長的時間來運行在AWS上我的筆記本電腦？

2.）任何人可以做的事情來加快generate_series功能？是否創建一個單獨的日曆表，然後加入該工作更快？

Answer 1

1）您的筆記本電腦行數較少。

AWS: (cost=17,814.33..7,931,812.83 rows=158,200,000 width=527) 
Laptop: (cost=15,238.52..4,002,252.94 rows=79,700,000 width=2,030) 

2）如果你打算多次使用該表，最好創建一個日曆表。 10年只有3650行，100年36k行