From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Cristian Veronesi <c(dot)veronesi(at)crpa(dot)it> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: index is not used if I include a function that returns current time in my query |
Date: | 2006-04-13 15:50:08 |
Message-ID: | 20558.1144943408@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Cristian Veronesi <c(dot)veronesi(at)crpa(dot)it> writes:
> If I try to use a function that returns the current time instead, a
> sequential scan is always performed:
> ...
> Any suggestion?
1. Use something newer than 7.4 ;-)
2. Set up a dummy range constraint, ie
select ... where ora_rif > localtimestamp and ora_rif < 'infinity';
The problem you have is that the planner doesn't know the value of the
function and falls back to a default assumption about the selectivity of
the '>' condition --- and that default discourages indexscans. (Note
the very large estimate of number of rows returned.) In the
range-constraint situation, the planner still doesn't know the value of
the function, but its default assumption for a range constraint is
tighter and it (probably) will choose an indexscan.
Since PG 8.0, the planner understands that it's reasonable to
pre-evaluate certain functions like localtimestamp to obtain
better-than-guess values about selectivity, so updating would
be a better fix.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2006-04-13 16:42:25 | Re: multi column query |
Previous Message | Oscar Picasso | 2006-04-13 15:40:06 | Re: Better index stategy for many fields with few values |