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
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 |