Re: How does the planner deal with multiple possible indexes? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: How does the planner deal with multiple possible indexes?
Date
Msg-id 16744.1153350040@sss.pgh.pa.us
Whole thread Raw
In response to Re: How does the planner deal with multiple possible indexes?  ("Gregory Maxwell" <gmaxwell@gmail.com>)
Responses Re: How does the planner deal with multiple possible indexes?  ("Jim C. Nasby" <jnasby@pervasive.com>)
List pgsql-hackers
"Gregory Maxwell" <gmaxwell@gmail.com> writes:
> On 7/19/06, Jim C. Nasby <jnasby@pervasive.com> wrote:
> [snip]
>> \d does list bdata__ident_filed_departure before bdata_ident; I'm
>> wondering if the planner is finding the first index with ident_id in it
>> and stopping there?

>> From my own experience it was grabbing the first that has the
> requested field as its first member.. I haven't looked at the code to
> see if that is the intended behavior.

Ordering would only matter if the estimated costs were exactly the same,
which they probably shouldn't be for indexes with such different sizes.
However, if the estimated number of matching rows were real small, you
might be winding up with a "one page to fetch" estimate in either case.
Jim didn't provide enough details to guess what the cost estimates
actually are...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: pgxs problem
Next
From: "Jim C. Nasby"
Date:
Subject: Freezing tuples on pages dirtied by vacuum