Re: How does the planner deal with multiple possible indexes?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Gregory Maxwell" <gmaxwell(at)gmail(dot)com>
Cc: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: How does the planner deal with multiple possible indexes?
Date: 2006-07-19 23:00:40
Message-ID: 16744.1153350040@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Gregory Maxwell" <gmaxwell(at)gmail(dot)com> writes:
> On 7/19/06, Jim C. Nasby <jnasby(at)pervasive(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-07-19 23:07:53 Freezing tuples on pages dirtied by vacuum
Previous Message Peter Eisentraut 2006-07-19 22:42:25 Re: pgxs problem