Hello,
I'm newly exposed to a Postgres 9.4 database system, and am
trying to understand how I might optimize a query that is taking
a long time to return.
What I'm observing is an uncached query that takes much much
longer to complete, sometimes minutes longer, when
enable_bitmapscan is true. Even after the query result is
cached, it seems to consistently be 300 ms slower when
enable_bitmapscan is true (so taking 900 ms to return instead of
600 ms).
This is on an AWS RDS Postgres 9.4 instance, backed by SSD, with
work_mem set to 1 gb (I'm not sure if that is a default or if
someone set it to that value on purpose). Autovacuum is on and
an ANALYSIS has been run against the db.
I'm hoping for some guidance from experts here on whether or not
I might be able to change something to get the query plan
selection to use the faster index scan that appears to be running
when the enable_bitmapscan is false. Or perhaps I should be
trying to craft a new index to reduce the chance that it needs
the bitmap?
I tried seeing whether or not reducing the random_page_cost from
the default 1.1 to 1.0 effected any change, and it does not.
Here's the part of the EXPLAIN that appears to change when
enable_bitmapscan is true:
-> Hash Left Join (cost=24696.39..594784.63 rows=11732 width=281)
Hash Cond: ((cr.cs_id)::text = (cm.raw_cs_id)::text)
-> Hash Join (cost=24680.76..594368.09 rows=11732 width=135)
Hash Cond: (cr.resource_id = r_1.id)
-> Bitmap Heap Scan on cs_resource cr (cost=6999.99..569213.13
rows=588549 width=27)
Recheck Cond: ((cs_id)::text = ANY
('{example.org,_zero_row_}'::text[]))
-> Bitmap Index Scan on cs_resource_by_cs_idx
(cost=0.00..6852.86 rows=588549 width=0)
Index Cond: ((cs_id)::text = ANY
('{example.org,_zero_row_}'::text[]))
-> Hash (cost=17576.61..17576.61 rows=8333 width=124)
-> Hash Right Join (cost=4132.63..17576.61 rows=8333 width=124)
Hash Cond: (pr.id = r_1.id)
-> Seq Scan on pub_resource pr (cost=0.00..8135.29
rows=418029 width=69)
-> Hash (cost=4028.47..4028.47 rows=8333 width=63)
-> Index Scan using "idx_1" on resource r_1
(cost=0.42..4028.47 rows=8333 width=63)
Index Cond: ((pl_id = 6) AND ((data_type_id)::text =
'DATABASE'::text))
-> Hash (cost=12.50..12.50 rows=250 width=292)
-> Seq Scan on cs_mappings cm (cost=0.00..12.50 rows=250 width=292)
compared to when enable_bitmapscan is false:
-> Hash Left Join (cost=17509.48..648717.08 rows=11732 width=281)
Hash Cond: (r_1.id = pr.id)
-> Hash Left Join (cost=4148.83..635121.79 rows=11732 width=228)
Hash Cond: ((cr.cs_id)::text = (cm.raw_cs_id)::text)
-> Hash Join (cost=4133.20..634705.25 rows=11732 width=82)
Hash Cond: (cr.resource_id = r_1.id)
-> Index Scan using "idx_2" on cs_resource cr
(cost=0.57..623098.44 rows=588549 width=27)
Index Cond: ((cs_id)::text = ANY
('{example.org,_zero_row_}'::text[]))
-> Hash (cost=4028.47..4028.47 rows=8333 width=63)
-> Index Scan using "idx_1" on resource r_1
(cost=0.42..4028.47 rows=8333 width=63)
Index Cond: ((pl_id = 6) AND ((data_type_id)::text =
'DATABASE'::text))
-> Hash (cost=12.50..12.50 rows=250 width=292)
-> Seq Scan on cs_mappings cm (cost=0.00..12.50 rows=250 width=292)
-> Hash (cost=8135.29..8135.29 rows=418029 width=69)
-> Seq Scan on pub_resource pr (cost=0.00..8135.29 rows=418029 width=69)
I'm not sure if the following details will be important to know,
but opting for more detail, here's an example of the query (which
returns 183 rows):
> EXPLAIN SELECT
data_type_id, title,
pub_name,
pl_name,
pl_id,
rpt_month,
cs_dsp_name,
cs_id,
grp_id ,
zpe,
sect_type,
sr_fed,
sr_reg,
r_v,
r_x_c,
prop_id
FROM report_view
WHERE pl_id IN (6)
AND data_type_id = 'DATABASE'
AND rpt_month between '2018-06-01' and '2018-06-30'
AND cs_id IN ( 'example.org' , '_zero_row_')
ORDER BY data_type_id ASC, CAST(title AS VARCHAR(256)) ASC, rpt_month ASC;
The underlying report_view that backs this query is... well, I'm
honestly having a very hard time wrapping my head around it (w/
original developer long gone).
I'll also note the tables it hits are massive, e.g., 265 gb for the
cs_resource_event table and 65 gb for the cs_resource table.
> \d+ report_view
View "public.report_view"
Column | Type | Modifiers |
Storage | Description
---+--+---+--+-
data_type_id | character varying(32)| | extended |
title | text | | extended |
zpe | integer | | plain|
pub_name | character varying| | extended |
pl_id | bigint
