selecting rows older than X, ensuring index is used

On Sat, 2005-08-20 at 15:33 -0700, CSN wrote:

Hi,

I want to select records that haven't had an error
(logged to last_error) in the last 24 hours. My query
is:

select * from table1
where last_error is null
or extract(epoch from now()-last_error) > 86400;

I don't know whether the planner would recognise that it could use an
index on that condition. How about

WHERE last_error IS NULL OR
last_error < (CURRENT_TIMESTAMP - '1 day'::INTERVAL)

which has the merit of being more readable.

I've created an index on last_error (timestamp with
time zone - can be NULL), then used EXPLAIN:

Seq Scan on table1 (cost=0.00..20.86 rows=217
width=72)
Filter: ((last_error IS NULL) OR
(date_part('epoch'::text, (now() - last_error)) >
86400::double precision))

There are over 550 rows in table1, so it doesn't look
the index is being used. Is there a way to rewrite
this query so the index is used?

The estimate is that nearly half of those 550 rows will be returned, so
a sequential scan would probably be chosen in any case.

--
Oliver Elphick olly@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA
========================================
Do you want to know God? http://www.lfix.co.uk/knowing_god.html

Oliver Elphick <olly@lfix.co.uk> writes:

On Sat, 2005-08-20 at 15:33 -0700, CSN wrote:

select * from table1
where last_error is null
or extract(epoch from now()-last_error) > 86400;

I don't know whether the planner would recognise that it could use an
index on that condition.

The "is null" isn't indexable, and an OR with a nonindexable condition
kills the entire point of considering an indexscan. (If you have to do
a seqscan anyway, there's no point in doing an indexscan too.)

You could probably make it work if you created a partial index with the
condition "last_error IS NULL"; then the planner could combine an
indexscan on that with an indexscan on a regular last_error index
(given refactoring of the other condition as Oliver recommends).

The estimate is that nearly half of those 550 rows will be returned, so
a sequential scan would probably be chosen in any case.

Yeah. Unless it's going to be a lot more selective than that, the
indexscan approach will be a loser anyway.

regards, tom lane