I have a table with ~5 million rows containing ranges of large (8-digit)
numbers. The table has an int4 field for the range start and the range end,
and a field which is null if that particular range is expired, and has a
value otherwise.
I need to query this table to find a range containing a particular number,
e.g. a query might look like this:
SELECT * FROM table_name WHERE range_start <= 87654321 AND range_end >=
87654321 AND expired IS NULL
My problem is that when I run a query like the above, the query planner does a
sequential scan, even though i have an index on both the query columns
separately, as well as an index containing both columns. The indexes are
defined like this:
CREATE INDEX range_start_end_index ON table_name USING btree (range_start,
range_end) WHERE expired IS NULL
CREATE INDEX range_start_index ON table_name USING btree (range_start) WHERE
expired IS NULL
CREATE INDEX range_end_index ON table_name USING btree (range_end) WHERE
expired IS NULL
When I do a query for smaller numbers (7-digit and below, as far as I can
see), the query planner uses the index(es) and the query is instantaneous.
However, when I run a query like the above, the planner decides to do a
sequential scan of the entire table.
I realize this probably has something to do with the planner only searching
for the first part of the WHERE clause (i.e. range_start <= 87654321) and
deciding that this will probably yield so many rows that a sequential scan
will yield results that are just as good. However, the data is structured in
such a way that multiple ranges containing the same number (and which are not
expired) do not exist. So in reality there will be either 1 or 0 results for
a query like the above.
How do I make the query planner realize that using the index is a Good
Thing(tm)?
Any help will be greatly appreciated.
Regards,
-Toke
