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

Re: Slow queries on big table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
Cc: "Tyrrill, Ed" <tyrrill_ed(at)emc(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow queries on big table
Date: 2007-05-18 20:06:09
Message-ID: 1825.1179518769@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
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:
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

In response to

Responses

pgsql-performance by date

Next:From: Heikki LinnakangasDate: 2007-05-18 20:19:00
Subject: Re: choosing fillfactor
Previous:From: Andrew KroegerDate: 2007-05-18 20:05:41
Subject: Re: Slow queries on big table

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