Index not picked when bind parameter can be null?

Question

Hi,
In my query i have a primary key say deptid and has an unique index defined.
when i do a query as
select * from dept where ((deptid = :pDeptId) or (:pDeptId is null))
index is not picked up and a full table scan happens.
Can one explain why?
Thanks
Manish

Answer 1

Solomon Yakobson wrote:
I purposely chose small table. Yes, optimizer calculated costs are such that FTS cost is same as combined cost of index fast scan + table access by rowid. And that is exactly what I am questioning. Set aside what you call "boundary" cases where rows are sparse enough (e.g. your example with lots of deleted rows) and similar scenarios (e.g. pctfree is very large, etc.) FTS is always less costly than index fast scan + table access by rowid by at least one IO. I understand, I am splitting hairs a bit since the difference is negligible, but still it is a sub-optimal plan.Solomon,
and yes, in those circumstances you describe the FTS will be chosen, so what is your point? Your test case represents such an "odd" scenario (sparse, large pctfree, etc., less rows than blocks, a clustering factor of the index less than the number of blocks of the table), so what do you want to prove using this test case? It doesn't represent the "normal" circumstances where the FTS is less costly.
In passing, the cost of the FTS and the combined operation are not the same in my default 10.2.0.4 database, the FTS is more expensive, as I've outlined previously.
The reason: It takes at least 1 multi-block I/O request to read the 5 blocks of the table. The optimizer assumes that the time it takes to perform a multi-block read request is 26ms when using default NOWORKLOAD system statistics with 8KB default block size. It assumes further it takes 12ms to perform a single-block read request, so the cost (expressed in single-block reads) of performing a single multi-block read request is 2.16. Since Oracle 9i, there is a hidden parameter "_table_scan_cost_plus_one" set to "true", it used to be "false" in 8i, making the cost 3.16, so we end up with a rounded cost of 3 for the FTS.
The cost of the combined index + table access is 2, one I/O for the index, plus one I/O for the table access. So from an optimizer perspective this plan is not sub-optimal, but the superior one, mainly due to the fact that one gets added to the table scan cost from 9i on, and you have the unusual clustering factor of 1.
As you can see, it takes a lot of "boundary" conditions that this happens, and it's all down to the fact that the table is so small, that is has only 4 rows in 5 blocks, and the clustering factor of the index is less than the number of blocks of the table, which is quite unusual. A "optimal" clustering factor usually corresponds to the number of blocks of the table, a "bad" clustering factor corresponds to the number of rows.
Therefore I suggested to "adjust" the clustering factor to a more usual value, but there is actually nothing usual about this test case since you have less rows than blocks.
So I guess you can say whatever you want about this being a "sub-optimal" plan, but I really don't see the point it makes, given the flawed test case. Run it with a more reasonable setup and the FTS will be used in those cases where it is reasonable according to the inputs the CBO gets.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/