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
