Re: get_actual_variable_range vs idx_scan/idx_tup_fetch

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
Дата
Msg-id 20141018182045.GF16974@momjian.us
обсуждение исходный текст
Ответ на Re: get_actual_variable_range vs idx_scan/idx_tup_fetch  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
Список pgsql-hackers
On Sat, Oct 18, 2014 at 06:15:03PM +0200, Marko Tiikkaja wrote:
> 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.

That is a good point.  Without an index, the executor is going to do a
sequential scan, while a missing index to the optimizer just means worse
statistics.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Optimizer on sort aggregate
Следующее
От: BRUSSER Michael
Дата:
Сообщение: initdb failure on RH 5.10