Re: Weird indices
От | Joseph Shraibman |
---|---|
Тема | Re: Weird indices |
Дата | |
Msg-id | 3A93154E.2FAEE331@selectacast.net обсуждение исходный текст |
Ответ на | Re: Weird indices (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Ответы |
Re: Weird indices
Re: Weird indices |
Список | pgsql-general |
Stephan Szabo wrote: > > On Tue, 20 Feb 2001, Joseph Shraibman wrote: > > > Stephan Szabo wrote: > > > > > Where are you seeing something that says the estimator/planner using the > > > index to get an upper bound? The estimator shouldn't be asking either the > > > index or the heap for anything, it should be working entirely with the > > > statistics that were generated from vacuum. > > > > Index Scan using usertable_p_key on usertable (cost=0.00..25.68 rows=50 > > width=72) > > > > That rows=50, which is an overestimate by the way. > > That's because the estimate in this case was 50 and so it's estimating > that going through the index and checking the heap is faster than a > sequence scan. The *estimator* didn't use the index to figure that out, > it's just saying that the best plan to actually *run* the query uses > the index. > IIRC, There's something which is effectively : > estimated rows = <most common value's frequency>*<fraction> > I think fraction defaults to (is always?) 1/10 for the standard > index type. That's where the 50 comes from. And the frequency is > probably from the last vacuum analyze. Then it should do the same thing no matter what value I use, but when I do different searches in one case it estimates 50 when there are 16 and in the other it estimeates 502 where there are 502. -- Joseph Shraibman jks@selectacast.net Increase signal to noise ratio. http://www.targabot.com
В списке pgsql-general по дате отправления: