From: Tom Lane <tgl@sss.pgh.pa.us>
To: Scott Marlowe <smarlowe@g2switchworks.com>
Cc: Tyrrill, Ed <tyrrill_ed@emc.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Slow queries on big table
Date: Fri, 18 May 2007 16:06:09 -0400
Message-ID: <1825.1179518769@sss.pgh.pa.us> (raw)
In-Reply-To: <464E0036.3030804@g2switchworks.com>
References: <A23190A408F7094FAF446C1538222F7603EE4245@avaexch01.avamar.com>
<464E0036.3030804@g2switchworks.com>
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.htmlhttp://www.postgresql.org/docs/8.2/static/indexes-bitmap-scans.html
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, smarlowe@g2switchworks.com, tyrrill_ed@emc.com
Subject: Re: Slow queries on big table
In-Reply-To: <1825.1179518769@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox