Re: Selectivity of "=" (Re: [HACKERS] Index not used on simple se lect)
От | Zeugswetter Andreas IZ5 |
---|---|
Тема | Re: Selectivity of "=" (Re: [HACKERS] Index not used on simple se lect) |
Дата | |
Msg-id | 219F68D65015D011A8E000006F8590C60339E096@sdexcsrv1.f000.d0188.sd.spardat.at обсуждение исходный текст |
Ответы |
Re: Selectivity of "=" (Re: [HACKERS] Index not used on simple se lect)
|
Список | pgsql-hackers |
> BTW, this argument proves rigorously that the selectivity of a search > for any value other than the MFOV is not more than 0.5, so there is some > basis for my intuition that eqsel should not return a value above 0.5. > So, in the cases where eqsel does not know the exact value being > searched for, I'd still be inclined to cap its result at 0.5. > Yes, this is imho an easy and efficient fix. I would even use a lower value, like 0,3. Good database design would not create an index for such bad selectivity anyway. So if you have a performance problem because of so bad selectivity, the advice is to drop the index. If you plan to store explicit key values, I would do this in an extra statistic, that stores bunches of equally sized buckets, and distinct values for very badly scewed values. Example assuming int index column: from to nrow_estimate 1 100 10005 101 20000 9997 20001 100000 10014 badly scewed values (excluded in above table): val nrow_estimate 1 100000 5 1000000 But imho this is an overkill, and seldom useful. Andreas
В списке pgsql-hackers по дате отправления: