Re: Unused indexes - PostgreSQL 9.2

Поиск
Список
Период
Сортировка
От Melvin Davidson
Тема Re: Unused indexes - PostgreSQL 9.2
Дата
Msg-id CANu8FizDB_GoKKNYHmYity+PNXS_P2=WukQrEyUK36bLc3gkyA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Unused indexes - PostgreSQL 9.2  (Lucas Possamai <drum.lucas@gmail.com>)
Ответы Re: Unused indexes - PostgreSQL 9.2  (Lucas Possamai <drum.lucas@gmail.com>)
Список pgsql-general


On Tue, May 10, 2016 at 5:17 PM, Lucas Possamai <drum.lucas@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.

В списке pgsql-general по дате отправления:

Предыдущее
От: Lucas Possamai
Дата:
Сообщение: Re: Unused indexes - PostgreSQL 9.2
Следующее
От: Lucas Possamai
Дата:
Сообщение: Re: Unused indexes - PostgreSQL 9.2