Can I trust the optimizer to do the right thing every time?

Question

Hello,
I have a Business Objects report that is performing poorly, I kind of found something akin to a solution but I'd like a second (and third, and...) opinion about is suitability. I don't know much about BO, so I'll stick to the SQL part.
So, the query looks something like that:
SELECT ..... FROM
-- this is the generic part of the report
< long list of ANSI joins here>
RIGHT JOIN some_table ON (conditions - non parametrizable from the report - not allowed by BO)
<some more joins for good measure>
-- end of the generic part, up to here nothing can take user parameters
WHERE
-- this is the specific part, from here on, the conditions can take user parameters
some_column = @some_param
....So far so simple. Now, I'm trying to find a way to push some user defined parameters in the generic part.
I can to this using package variables, something like that (very simplified form) :
CREATE OR REPLACE PACKAGE vars AS
my_filter VARCHAR2(100);
FUNCTION set_filter(filter_val IN VARCHAR2) return number;
END vars;
CREATE OR REPLACE PACKAGE BODY vars AS
FUNCTION set_filter(filter_val IN VARCHAR2) return number DETERMINISTIC IS
      my_filter := filter_val;
      return 1;
END set_filter;
END vars;And ask the developers to rewrite the report like that:
SELECT ..... FROM
-- this is the generic part of the report
< long list of ANSI joins here>
RIGHT JOIN some_table ON (conditions  - as above
                                                *AND my_varchar_column = vars.my_filter*)
<some more joins for good measure>
-- end of the generic part, up to here nothing can take user parameters
WHERE
-- this is the specific part, from here on, the conditions can take user parameters
some_column = @some_param
*AND vars.set_filter('some text here') = 1*
....The question is, can I trust the optimizer to evaluate my where clause (thus executing set_filter) before trying to enter the joins?
I know that this works nicely with conditions like "1=0", in this case it doesn't even bother to read the tables involved. But can I assume it will do the same with a pl/sql function? Always?
In my tests it seems to work but obviously they are not exhaustive. So I guess what I'm asking is, can anyone imagine a scenario where the above would fail?
Thanks,
Iulian
Edited by: Iulian J. Dragan on Feb 27, 2013 2:57 AM

Answer 1

Iulian J. Dragan wrote:
Even though I tell the optimizer, "look, this function is ridiculously expensive, plus it won't filter any rows" it keeps evaluating it first.
So it looks like not only can I rely on Oracle to evaluate a literal expression first, much as I try I can't make it behave otherwise.
Still, this is only empirical, I wouldn't use it in a production environment. Probably...Iulian,
I think I understand what you are trying to do here. Something like using cost to drive the optimizer to process the SQL statement "procedurely"...
But I believe SQL, by definition, is a set-based language and this means one can not rely on the way an SQL statement is executed by the oracle engine.
I believe this is good in most of the situations. However, I understand that it is possible that one may want to use his/her knowledge of the data to write
SQL so that it is more efficient. CBO, being a software, has its limitations and may not always make the right decision, depending upon complexity of rewrite.
I don't know enough about your original problem, which involves a third-party product i.e. Business Objects, but there is a way in your example to enforce
the sequence in which he functions are called.
Here is your code, as it is, producing the results that you have demonstrated:
SQL> select * from v$version ;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE     11.2.0.1.0     Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
SQL> create table testtab(n number) cache;
Table created.
SQL> insert into testtab values(1);
1 row created.
SQL> commit;
Commit complete.
SQL> exec dbms_stats.gather_table_stats(user, 'TESTTAB', METHOD_OPT=>'FOR ALL COLUMNS SIZE 1');
PL/SQL procedure successfully completed.
SQL> create or replace function testfunc(p in varchar2)
  2  return number
  3  as
  4  begin
  5    dbms_application_info.set_client_info('executed with argument ' || p);
  6    return 1;
  7  end testfunc;
  8  /
Function created.
SQL> select * from testtab where n=5 and testfunc('no worries')=1;
no rows selected
SQL> select sys_context('USERENV', 'CLIENT_INFO') from dual;
SYS_CONTEXT('USERENV','CLIENT_INFO')
executed with argument no worries
SQL> create or replace function testfunc(p in varchar2)
  2  return number
  3  as
  4  begin
  5    dbms_application_info.set_client_info(sys_context('USERENV', 'CLIENT_INFO') || '|testfunc with argument ' || p);
  6    return 1;
  7  end testfunc ;
  8  /
Function created.
SQL> create or replace function testfunc2(p in varchar2)
  2  return number
  3  as
  4  begin
  5    dbms_application_info.set_client_info(sys_context('USERENV', 'CLIENT_INFO') || '|testfunc2 with argument ' || p);
  6    return p;
  7  end testfunc2;
  8  /
Function created.
SQL> EXEC dbms_application_info.set_client_info('');
PL/SQL procedure successfully completed.
SQL> select * from testtab where testfunc2(n)=5   and testfunc('am I first?')=1;
no rows selected
SQL> select sys_context('USERENV', 'CLIENT_INFO') from dual;
SYS_CONTEXT('USERENV','CLIENT_INFO')
|testfunc with argument am I first?|testfunc2 with argument 1
SQL> EXEC dbms_application_info.set_client_info('');
PL/SQL procedure successfully completed.
SQL> select * from testtab where testfunc2(n)=1 and testfunc('so lonely...') = 0;
no rows selected
SQL> select sys_context('USERENV', 'CLIENT_INFO') from dual;
SYS_CONTEXT('USERENV','CLIENT_INFO')
|testfunc with argument so lonely...I have left out the statistics association part above as I believe it does not affect.
And below is the rewritten queries that result in functions being called in specific order
SQL> EXEC dbms_application_info.set_client_info('');
PL/SQL procedure successfully completed.
SQL> select * from testtab where decode(testfunc2(n),5,testfunc('am I first?'))=1;
no rows selected
SQL> select sys_context('USERENV', 'CLIENT_INFO') from dual;
SYS_CONTEXT('USERENV','CLIENT_INFO')
|testfunc2 with argument 1
SQL> EXEC dbms_application_info.set_client_info('');
PL/SQL procedure successfully completed.
SQL> select * from testtab where decode(testfunc2(n), 1, testfunc('so lonely...')) = 0;
no rows selected
SQL> select sys_context('USERENV', 'CLIENT_INFO') from dual;
SYS_CONTEXT('USERENV','CLIENT_INFO')
|testfunc2 with argument 1|testfunc with argument so lonely...One can also use the more flexible CASE expressions in place of DECODE.
Hope this helps.