Re: slow index lookup

The combination index works great. Would adding the combination index
guarantee that the optimizer will choose that index for these kind of
queries involving the columns in the combination. I verified a couple
of times and it picked the right index. Just wanted to make sure it
does that consistently.

On Tue, Jun 22, 2010 at 7:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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
>