Potentially, there was an index which the author knew would yield good performance for a particular query, but the query planner over-estimated the number of rows, and so decided that a sequential scan would be a better choice. By executing the command, "SET enable_seqscan = OFF;" inside a session, you can force postgres to use an index if it possibly can.

These sort of problems can occur (for example) when very complicated joins are performed, or when unstructured data is being used as part of a join, as these tend to lead to poor estimates of the number of rows that the different parts of the query will yeild.

Relevant docs here:

https://www.postgresql.org/docs/current/static/runtime-confi...

You can intentionally do calculations to 'break’ indexes and take them out of consideration. (E.g., pg will tend to prefer scanning a primary key index if you're ordering by that in the query. Sometimes this is a very poor choice if there's a more selective index)

There are also statistics that can be tweaked on vacuum analyze to improve the accuracy of the planner.

Another technique that gets used a fair amount to force certain planner behaviors are CTEs. I've used these to great effect in some rather complex queries where performance was critical.

A good start to understanding how these work in an optimization context is: http://blog.2ndquadrant.com/postgresql-ctes-are-optimization...

There are different ways you can write queries that result in equivalent results. For instance you might try using inner joins, sub selects, lateral joins, etc.