Re: Slow queries on big table

Tom Lane <tgl@sss.pgh.pa.us> writes:
>
> Scott Marlowe <smarlowe@g2switchworks.com> writes:
> > Secondly, it might be more efficient for the planner to choose the
> > backup_location_rid index than the combination primary key index.
>
> Oh, I'm an idiot; I didn't notice the way the index was set up.
> Yeah, that index pretty well sucks for a query on backup_id ---
> it has to scan the entire index, since there's no constraint on the
> leading column.
> So that's where the time is going.
>
> This combination of indexes:
>
> > Indexes:
> >     "backup_location_pkey" PRIMARY KEY, btree (record_id, backup_id)
> >     "backup_location_rid" btree (record_id)
>
> is really just silly.  You should have the pkey and then an index on
> backup_id alone.  See the discussion of multiple indexes in the fine
> manual:
> http://www.postgresql.org/docs/8.2/static/indexes-multicolumn.html
> http://www.postgresql.org/docs/8.2/static/indexes-bitmap-scans.html
>
>             regards, tom lane

Thanks for the help guys!  That was my problem.  I actually need the
backup_location_rid index for a different query so I am going to keep
it.  Here is the result with the new index:

mdsdb=# explain analyze select record_id from backup_location where
backup_id = 1070;
                                                                   QUERY
PLAN

------------------------------------------------------------------------
------------------------------------------------------------------------
 Index Scan using backup_location_bid on backup_location
(cost=0.00..9573.07 rows=415897 width=8) (actual time=0.106..3.486
rows=2752 loops=1)
   Index Cond: (backup_id = 1070)
 Total runtime: 4.951 ms
(3 rows)