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