> > > 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 = off > > before 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
