Skip site navigation (1) Skip section navigation (2)

Re: Slow queries on big table

From: "Tyrrill, Ed" <tyrrill_ed(at)emc(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Scott Marlowe" <smarlowe(at)g2switchworks(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Slow queries on big table
Date: 2007-05-18 21:22:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Scott Marlowe <smarlowe(at)g2switchworks(dot)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:
> 			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;

 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)

In response to


pgsql-performance by date

Next:From: Steinar H. GundersonDate: 2007-05-18 21:28:23
Subject: Re: Slow queries on big table
Previous:From: Heikki LinnakangasDate: 2007-05-18 20:19:00
Subject: Re: choosing fillfactor

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group