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 54418ED1.4020201@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
Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
Список pgsql-hackers
On 10/17/14, 11:47 PM, Tom Lane wrote:
> Marko Tiikkaja <marko@joh.to> writes:
>> This week we had one of the most annoying problems I've ever encountered
>> with postgres.  We had a big index on multiple columns, say,  foo(a, b,
>> c).  According to pg_stat_all_indexes the index was being used *all the
>> time*.  However, after looking into our queries more closely, it turns
>> out that it was only being used to look up statistics for the foo.a
>> column to estimate merge scan viability during planning.  But this took
>> hours for two people to track down.
>
>> So what I'd like to have is a way to be able to distinguish between
>> indexes being used to answer queries, and ones being only used for stats
>> lookups during planning.
>
> Why?  Used is used.

Because I don't need a 30GB index on foo(a,b,c) to look up statistics. 
If I ever have a problem, I can replace it with a 5GB one on foo(a).


.marko



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

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