From: | Melvin Davidson <melvin6925(at)gmail(dot)com> |
---|---|
To: | Lucas Possamai <drum(dot)lucas(at)gmail(dot)com> |
Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Unused indexes - PostgreSQL 9.2 |
Date: | 2016-05-10 21:20:14 |
Message-ID: | CANu8FizDB_GoKKNYHmYity+PNXS_P2=WukQrEyUK36bLc3gkyA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, May 10, 2016 at 5:17 PM, Lucas Possamai <drum(dot)lucas(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Lucas Possamai | 2016-05-10 21:23:18 | Re: Unused indexes - PostgreSQL 9.2 |
Previous Message | Lucas Possamai | 2016-05-10 21:17:17 | Re: Unused indexes - PostgreSQL 9.2 |