postgres generate_series performance slower on server then laptop - postgresql

Question

I have a series of views that build off of each other like this:
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
In this view..rpt_scn_appl_target_unnest_timeseries_v, I use the generate_series function to generate monthly rows between 1/1/2015 and 12/31/2019.
what I've noticed is this:
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
I've noticed that commenting out the generate_series code in the view, the query runs in under a second, but with it, it takes 10secs to run...
rpt_scn_appl_target_unnest_timeseries_v View:
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;
What I've also noticed too is that performance between the database on my laptop and the AWS rds server with the same data, tables, and views..is faster on my laptop even though it has much less ram and cpu. I'm running postgres 9.6 on my laptop and 9.6 on AWS rds. My laptop is macbook pro with 16gb of ram and i7 dual core. For rds, I'm using a m4.4xlarge which is 16 cores and 64gb of ram.
Here is the AWS explain plan:
https://explain.depesz.com/s/UGF
My laptop explain plan:
https://explain.depesz.com/s/zaWt
So I guess my questions are:
1.) why is the query taking longer to run on AWS then my laptop?
2.) anything one can do to speed up generate_series function? Does creating a separate calendar table and then joining to that work faster?

Answer 1

1) Your laptop has fewer rows.
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) If you are going to use the table several times, is better create a calendar table. 10 years is only 3650 rows, 100 years 36k rows