postgres generate_series在服务器和笔记本电脑上的性能较慢

时间:2016-12-14 15:50:53

标签: postgresql

我有一系列的观点,彼此相互建立:

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函数生​​成2015年1月1日到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代码,查询会在一秒钟内运行,但是使用它,需要10秒才能运行...

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服务器之间的性能在笔记本电脑上的速度更快,即使它的内存少得多,中央处理器。我在笔记本电脑上运行了postgres 9.6,在AWS rds上运行了9.6。我的笔记本电脑是macbook pro,配备16GB内存和i7双核。对于rds,我使用m4.4xlarge,它是16核和64gb ram。

以下是AWS解释计划: https://explain.depesz.com/s/UGF

我的笔记本解释计划: https://explain.depesz.com/s/zaWt

所以我想我的问题是:

1。)为什么查询需要更长时间才能在AWS和笔记本电脑上运行?

2。)可以做些什么来加速generate_series功能?是否创建了一个单独的日历表,然后更快地加入该工作?

1 个答案:

答案 0 :(得分:0)

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行

相关问题