"Tyrrill, Ed" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
