create index t1_fbi on t1(nvl(end_date,to_date('31-dec-4000','dd-mon-yyyy')))


The drawback to this ‘year 4000′ hack, though, is that it distorts the optimizer’s view of your data, so you will need to generate a histogram on the ‘virtual column’ so that the optimizer knows that the year 4000 data is a very odd outlier. There is a method_opt of “for all hidden columns” that you can use with the dbms_stats procedures to do this.

where … and ( end_date is null or end_date > sysdate)

Since these clause had to be repeated many times, developers quickly figured out a typing shortcut:

where … and nvl(end_date, sysdate+1/1400)>sysdate

The problem was that at the beginning most of the items were open and consequently index access path based on the above predicate wouldn’t make much sense in many cases as it would need almost every single row from a given table. As the system grew however, many items became “expired” and the above predicate became fairly selective (no archiving of any sort was used for that system).

Is there a good generic enough solution for this problem? Something along the lines of conditional plan you demonstrated in this article perhaps? Function based indexes just came around back than (beginning of 8i) and we haven’t tried them out. Would they work in this case?

Just wanted to mention that while reading this article I remembered that I saw a similar piece couple of years ago back in the 8i/9i days, which was the reason to use NVL quite extensively in our code:

http://www.oracle.com/technology/oramag/oracle/03-jul/o43asktom.html

(scroll down to the “How to Write this Query”)

Thanks,
Boris Dali.

I am intrested in knowing the solution on this.

I am thinking of using something like this to get around this issue.

select *
from t1
where nvl(t1.n1,’$') = nvl(:n1,nvl(t1.n1,’$'))
;

PS: n1 is not indexed and is not date datatype column.

Appreciate your feedback on this.

Thanks
KB

Next time I will make sure ,I will post the code.
Thank you
CT