Michael Nachbaur <mike@nachbaur.com> writes:
>-> Merge Join (cost=6106.42..6335.30 rows=2679 width=265) (actual time=859.77..948.06 rows=1 loops=1)
> -> Merge Join (cost=6101.24..6319.77 rows=2679 width=247) (actual time=554.11..674.17 rows=2679 loops=1)
> -> Index Scan using customer_id_key on customer c (cost=0.00..129.63 rows=2679 width=156) (actual
time=0.40..43.43rows=2679 loops=1)
> -> Sort (cost=6101.24..6101.24 rows=8117 width=91) (actual time=553.64..559.58 rows=8117 loops=1)
> -> Seq Scan on customer_month_summary cms (cost=0.00..5574.17 rows=8117 width=91) (actual
time=258.03..477.11rows=8117 loops=1)
You should send the query as well, and \d customer_month_summary so we can see
how you defined your indexes.
There doesn't seem to be a filter on the scan so it looks like postgres thinks
you're actually reading in the entire table, which is normally faster with a
sequential scan than an index scan. In fact I'm surprised it's doing an index
scan on the other table and not a sequential scan.
Some things to try:
set enable_seqscan = off
Then try your query again, see if postgres is right and it really is faster to
do the sequential scan.
set random_page_cost = 2
Or even lower values.
I've also had some success with raising cpu_tuple_cost, though I'm unclear on
whether that's actually a good approach or not.
Also, don't forget to do a vacuum full on these tables before doing
testing for optimizations at this level. You can get some confusing results if
your tables have lots of empty holes in them.
--
greg