Long dynamic query not optimized ?

Question

I have a stored procedure that dynamically builds a query string and then executes it.
I noticed that above certain number of WHERE conditions the query is much slower, even if the new conditions are always true (1=1).
Details:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0
procedure findStuff(
     p_a IN CHAR,
     p_b IN CHAR,
     p_c IN INTEGER,
     p_d IN SMALLINT,
     p_e IN VARCHAR2, -- and a few more parameters, omitted here...
     p_out out sys_refcursor)
is
    sqlQuery VARCHAR2(2024);
begin
     sqlQuery := 'select T1.* from T1 ' ||
            'where BAR1 = :c_false ';
     IF p_a IS NOT NULL THEN
          sqlQuery := sqlQuery || 'AND FOO_A=:p_a ';
     ELSE
          sqlQuery := sqlQuery || 'AND ((1=1) OR :p_a IS NULL) ';
     END IF;
     IF p_b IS NOT NULL THEN
          sqlQuery := sqlQuery || 'AND FOO_B=:p_b ';
     ELSE
          sqlQuery := sqlQuery || 'AND ((1=1) OR :p_b IS NULL) ';
     END IF;
     IF p_c IS NOT NULL THEN
          sqlQuery := sqlQuery || 'AND FOO_C=:p_c ';
     ELSE
          sqlQuery := sqlQuery || 'AND ((1=1) OR :p_c IS NULL) ';
     END IF;
-- and a few more like that, for each input parameter...
-- c_false is a constant, defined in the package body
               OPEN p_out FOR sqlQuery USING c_false, p_a, p_b, p_c, p_d,...;
end;The issue is, that this query takes about 0.34 seconds on my database, but if I remove two parameters (an IF block above) then it runs in 0.06 seconds.
Even if the corresponding parameter has the values NULL (so in efect I just removed a "AND ((1=1) OR NULL IS NULL) ".
Am I running into some limit here?
What are my options, besides removing some rarely used parameters from the procedure?
Is this some server setting (can it become an issue again later, even if I remove some conditions from the query) ?
Regard,
David

Answer 1

xerces8 wrote:
Am I running into some limit here?
What are my options, besides removing some rarely used parameters from the procedure?How many parameters are we talking about here in reality?
Either way you should check out the following: {message:id=9360003}
Also the approach you are taking is a pre-11.2. You should probably adopt the new approach that uses DBMS_SQL.TO_REFCURSOR function. Here is an (untested) example:
DECLARE
     l_cursor NUMBER := DBMS_SQL.OPEN_CURSOR;
     l_refcursor SYS_REFCURSOR;
     l_sql       VARCHAR2(250) := 'SELECT * FROM foo WHERE 1=1 ';
BEGIN
     IF p_a IS NOT NULL THEN
          l_sql := l_sql || ' AND p_a = :b_a';
     END IF;
     IF p_b IS NOT NULL THEN
          l_sql := l_sql || ' AND p_b = :b_b';
     END IF;
     DBMS_SQL.PARSE(l_cursor, l_sql, DBMS_SQL.NATIVE);
     IF p_a IS NOT NULL THEN
          DBMS_SQL.BIND_VARIABLE(l_cursor,'b_a',p_a);
     END IF;
     IF p_b IS NOT NULL THEN
          DBMS_SQL.BIND_VARIABLE(l_cursor,'b_b',p_b);
     END IF;     
     DBMS_SQL.EXECUTE(l_cursor);
     l_refcursor := DBMS_SQL.TO_REFCURSOR(l_cursor);
END;
/Edited by: Centinul on Jul 12, 2011 8:01 AM