On Sat, 2 Oct 2004 08:06 am, Ryan VanMiddlesworth wrote:

[snip]
> 
> 
> Here is the query and EXPLAIN that runs quickly:
>   SELECT case_id FROM case_data 
>   WHERE case_filed_date > '2004-09-16' 
>     AND case_filed_date < '2004-09-20'
> 
>                        QUERY PLAN
> -------------------------------------------------------------
> Index Scan using case_data_case_filed_date on case_data  
> (cost=0.00..13790.52 rows=3614 width=18)
>   Index Cond: ((case_filed_date > '2004-09-16'::date) 
>            AND (case_filed_date < '2004-09-20'::date))
> 
> 
> And here is the query and EXPLAIN from the version that I believe the planner 
> should reduce to be logically equivalent:
>  SELECT case_id FROM case_data 
>  WHERE (('2004-09-16' IS NULL) OR (case_filed_date > '2004-09-16'))
>    AND (('2004-09-20' IS NULL) OR (case_filed_date < '2004-09-20'))
> 
>                        QUERY PLAN
> -------------------------------------------------------------
> Seq Scan on case_data  (cost=0.00..107422.02 rows=27509 width=18)
>   Filter: ((('2004-09-16' IS NULL) OR (case_filed_date > '2004-09-16'::date))
>        AND (('2004-09-20' IS NULL) OR (case_filed_date < '2004-09-20'::date)))
> 
> 
> I was hoping that the null comparisons would get folded out by the planner 
> relatively cheaply. But as you can see, the first query uses indexes and the 
> second one uses sequence scans, thereby taking much longer.  I guess my 
> question is - is there a better way to accomplish what I'm doing in SQL or am 
> I going to have to dynamically generate the statement based on supplied 
> parameters?
> 
The Index does not store NULL values, so you have to do a tables scan to find NULL 
values.
That means the second query cannot use an Index, even if it wanted to.

Regards

Russell Smith


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org

Reply via email to