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

In response to

Responses

pgsql-performance by date

Next:From: Abu MushayeedDate: 2007-05-18 21:37:27
Subject: Re: CPU Intensive query
Previous:From: Steinar H. GundersonDate: 2007-05-18 21:28:23
Subject: Re: Slow queries on big table

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