Thursday, 19 September 2013

PostgreSQL need VACUUM or ANALYZE schedule to make use of indexes?

PostgreSQL need VACUUM or ANALYZE schedule to make use of indexes?

I am creating indexes to tables in an existing PostgreSQL database
instance. I understand that EXPLAIN ANALYZE followed by the application's
SQL command is the easiest way to know whether my indexes are being used.
For example:
EXPLAIN ANALYZE SELECT A,B,C FROM MY_TABLE WHERE C=123;
Would give me back:
Seq Scan on public.my_table (cost=...) <- No index, BAD
And, after creating the index, it would return:
Index Scan using my_index_name on public.my_table (cost=...) <- Index, GOOD
In my optimisation task, I found a relatively big table that suffered the
occasional performance problem and created an index for that. That was a
perfect example of turning a sequential scan into an index scan as above.
It worked.
However, after creating the index, the second query that ranked the
slowest on the list, still less than 0.5 seconds that is, the index didn't
make any difference! After the index created, it would still do the Seq
Scan. The table has a few hundred records though, but likely to grow a few
thousand a year.
Digging a little deeper in the PostgreSQL documentation it says it would
still use the sequential scan when no significant performance gains were
given by using the said index.
Then the scary part: there was a recommendation that you run ANALYZE or
have the "Autovacuum" daemon on. This way the database would know the size
of tables and decide on query plans properly.
I understand using indexes is fairly basic, so is this absolutely
necessary in a production environment? In other words, will PostgreSQL use
the index when it's time to use it without need to analyse or vacuum as an
extra task?

No comments:

Post a Comment