Re: Forcing query to use an index

Michael Nachbaur <mike(at)nachbaur(dot)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.43 rows=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.11 rows=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