Re: Query planner problem

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