pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tyrrill, Ed <tyrrill_ed@emc.com>
Cc: Scott Marlowe <smarlowe@g2switchworks.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Slow queries on big table
Date: Fri, 18 May 2007 17:36:40 -0400
Message-ID: <3126.1179524200@sss.pgh.pa.us> (raw)
In-Reply-To: <A23190A408F7094FAF446C1538222F7603EE4372@avaexch01.avamar.com>
References: <A23190A408F7094FAF446C1538222F7603EE4245@avaexch01.avamar.com>
	<464E0036.3030804@g2switchworks.com>
	<1825.1179518769@sss.pgh.pa.us>
	<A23190A408F7094FAF446C1538222F7603EE4372@avaexch01.avamar.com>

"Tyrrill, Ed" <tyrrill_ed@emc.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> 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.

> 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.

Well, you don't really *need* it; the two-column index on (record_id,
backup_id) will serve perfectly well for queries on its leading column
alone.  It'll be physically bigger and hence slightly slower to scan
than a single-column index; but unless the table is almost completely
read-only, the update overhead of maintaining all three indexes is
probably going to cost more than you can save with it.  Try that other
query with and without backup_location_rid and see how much you're
really saving.

>  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

That's more like it ;-)

			regards, tom lane



view thread (9+ messages)  latest in thread

Message-ID: <3126.1179524200@sss.pgh.pa.us>
Permalink:  ../3126.1179524200@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3126.1179524200@sss.pgh.pa.us

 · 

reply

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, tyrrill_ed@emc.com, smarlowe@g2switchworks.com
  Subject: Re: Slow queries on big table
  In-Reply-To: <3126.1179524200@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