Re: Unused indexes - PostgreSQL 9.2
| От | Lucas Possamai |
|---|---|
| Тема | Re: Unused indexes - PostgreSQL 9.2 |
| Дата | |
| Msg-id | CAE_gQfX+90LQZqejgEWaLTAChLWuZia42_xEXaNB=9GhVmKqrw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Unused indexes - PostgreSQL 9.2 (Melvin Davidson <melvin6925@gmail.com>) |
| Ответы |
Re: Unused indexes - PostgreSQL 9.2
|
| Список | pgsql-general |
Sorry, I was too busy looking at the content.Has the size / # rows changed recently? If the planner thinks it can load all the rows faster, it will use a seqscan regardless if you have an index.If that is the case, you can force index use by doing a
SET enable_seqscan = offbefore executing the query.
Hmm... ok... but the situation is:
1 - I dropped the index
2 - Found a very slow query
3 - The "WHERE" clause was using the index that I've just dropped
4 - I ran the query in my test environment (Same DB as prod) with explain analyze to see if the query was indeed using the index I've dropped
5 - Yes, the query was using the index
6 - re-created the index
7 - The total time went from 2000ms to 200ms
So, I don't think the index was indeed not being used.
I believe the stats are not working, just don't know how to confirm that, as I have nothing on my logs
В списке pgsql-general по дате отправления: