On Tue, May 10, 2016 at 5:17 PM, Lucas Possamai <drum.lu...@gmail.com> wrote:
> >> 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 > >Some time ago I changed the pg_stat_temp directory from /var/lib/pgsq/whatever to /tmp Have you checked the postgres log to see if there are any errors about it not being able to write to the pg_stat_temp dir? -- *Melvin Davidson* I reserve the right to fantasize. Whether or not you wish to share my fantasy is entirely up to you.
