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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
Следующее
От: Tom Lane
Дата:
Сообщение: FieldSelect optimization versus overall planner organization