Re: slow index lookup

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Anj Adu <fotographs(at)gmail(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: slow index lookup
Date: 2010-06-23 02:01:53
Message-ID: 11812.1277258513@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Anj Adu's message of mar jun 22 17:44:39 -0400 2010:
>> This query seems unreasonable slow on a well-indexed table (13 million
>> rows). Separate indexes are present on guardid_id , from_num and
>> targetprt columns.

> Maybe you need to vacuum or reindex?

Rethinking the set of indexes is probably a more appropriate suggestion.
Separate indexes aren't usefully combinable for a case like this --- in
principle the thing could do a BitmapAnd, but the startup time would be
pretty horrid, and the LIMIT 1 is discouraging it from trying that.
If this is an important case to optimize then you need a 3-column index.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Anj Adu 2010-06-23 03:05:20 Re: slow index lookup
Previous Message Anj Adu 2010-06-23 01:21:46 Re: slow index lookup