Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
От | Marko Tiikkaja |
---|---|
Тема | Re: get_actual_variable_range vs idx_scan/idx_tup_fetch |
Дата | |
Msg-id | 54429207.6060307@joh.to обсуждение исходный текст |
Ответ на | Re: get_actual_variable_range vs idx_scan/idx_tup_fetch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
|
Список | pgsql-hackers |
On 10/18/14, 5:46 PM, Tom Lane wrote: > Marko Tiikkaja <marko@joh.to> writes: >> Yes, exactly; if I had had the option to disable the index from the >> optimizer's point of view, I'd have seen that it's not used for looking >> up any data by any queries, and thus I would have known that I can >> safely drop it without slowing down queries. Which was the only thing I >> cared about, and where the stats we provide failed me. > > This argument is *utterly* wrongheaded, because it assumes that the > planner's use of the index provided no benefit to your queries. If the > planner was touching the index at all then it was planning queries in > which knowledge of the extremal value was relevant to accurate selectivity > estimation. So it's quite likely that without the index you'd have gotten > different and inferior plans, whether or not those plans actually chose to > use the index. Maybe. But at the same time that's a big problem: there's no way of knowing whether the index is actually useful or not when it's used only by the query planner. .marko
В списке pgsql-hackers по дате отправления: