-Yasser

Your reference to the cardinality hint was almost in passing, but I found it most interesting and useful in my situation. My developers have recently gotten into the habit of writing queries like this inside of PL/SQL programs:


select ....
from mytab
where job_code in (select code from table(cast(myvar as mytype))) and ....


where myvar is an Oracle variable of a user-defined table type. It bothered me greatly to see full table scans on the very large mytab table when I knew that the myvar variable contained just a handful of values. But I knew of no way to persuade the CBO to do the preferred index access instead of an FTS. The cardinality hint is just perfect in our case, and now I’ll be recommending something of this form:


select ....
from mytab
where job_code in (select /*+ cardinality (pv 10) */ code 
                   from table(cast(myvar as mytype)) pv) and ....


I’ve tested this quite a bit and I’m very pleased with the results. Thank you for the suggestion!

I do, however, have a followup question. In most cases, I can reasonably predict the number of rows in the table variables that I’ll discuss with my developers. Are you aware of any other mechanisms that I could employ to dynamically inform the CBO of the sizes of the table variables so that it could decide the best execution path?

This may be a non-concern because there are obvious drawbacks to putting more than a few values into any table variable. I’m thinking PGA here, of course.

Thanks for your time.

You’re quite right.

I was using the function to demonstrate a point – but I should have said something to make it clear that it was a deliberate abuse of the “deterministic” key word.

(In Practical 8i, I made the point very clearly by creating a function that returned the result of a call to the dbms_random package.)

I’ve witnessed things such as intermittent ORA-600 errors and even plain wrong (and not just stale) results when declaring functions that aren’t really deterministic as deterministic. Think about it… If a function is deterministic Oracle may or may not call the function a second/third/… time (it may need to call it a second time, if the result is not longer cached, but I believe it may choose to call it again for a number of reasons). When you lie to Oracle “all bets are off” – be careful!

A function which passes the CLOB as its input could well be more efficient than any other option – it’s something I would want to test before implementing a live solution.

I will be posting a couple of other notes about the oddities (and overheads) of manipulating LOBs at some future date.

Michael,
Good point about the deterministic declaration. I typed that in on auto-pilot without thinking about it – you’re right, it shouldn’t be there and I’ve taken it out.

Well then, declare the function to take the CLOB as an IN parameter instead of the ID. Would be deterministic and save a “context switch”, too. Although one could question the benefit of it being deterministic in this case (don’t know if SQL can cache function results for functions with LOB parameters, or for pipelined functions, for that matter)

Flado

Declaring the function to be deterministic is wrong! It selects the clob from a database table, so it cannot be guaranteed to return the same result the next time it is called (with the same parameters)…

Regards,
Michael