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 54427B6D.80306@joh.to
обсуждение исходный текст
Ответ на Re: get_actual_variable_range vs idx_scan/idx_tup_fetch  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
Список pgsql-hackers
On 10/18/14, 4:33 PM, Bruce Momjian wrote:
> On Sat, Oct 18, 2014 at 04:29:41PM +0200, Marko Tiikkaja wrote:
>> Another idea had was some way to tell the optimizer not to use that
>> particular index for stats lookups, but probably the use case for
>> such a feature would be a bit narrow.
>
> Well, if the index is there, why not use it?  I thought the problem was
> just that you had no visibility into how those statistics were being
> accessed.

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.


.marko



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Hash index creation warning
Следующее
От: Thomas Kellerer
Дата:
Сообщение: Re: Materialized views don't show up in information_schema