Performance issues with pipelined table functions

Question

I am testing pipelined table functions to be able to re-use the <font face="courier">base_query</font> function. Contrary to my understanding, the <font face="courier">with_pipeline</font> procedure runs 6 time slower than the legacy <font face="courier">no_pipeline</font> procedure. Am I missing something? The <font face="courier">processor</font> function is from [url http://www.oracle-developer.net/display.php?id=429]improving performance with pipelined table functions .
Edit: The underlying query returns 500,000 rows in about 3 minutes. So there are are no performance issues with the query itself.
Many thanks in advance.
CREATE OR REPLACE PACKAGE pipeline_example
IS
   TYPE resultset_typ IS REF CURSOR;
   TYPE row_typ IS RECORD (colC VARCHAR2(200), colD VARCHAR2(200), colE VARCHAR2(200));
   TYPE table_typ IS TABLE OF row_typ;
   FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
      RETURN resultset_typ;
   c_default_limit   CONSTANT PLS_INTEGER := 100;  
   FUNCTION processor (
      p_source_data   IN resultset_typ,
      p_limit_size    IN PLS_INTEGER DEFAULT c_default_limit)
      RETURN table_typ
      PIPELINED
      PARALLEL_ENABLE(PARTITION p_source_data BY ANY);
   PROCEDURE with_pipeline (argA          IN     VARCHAR2,
                            argB          IN     VARCHAR2,
                            o_resultset      OUT resultset_typ);
   PROCEDURE no_pipeline (argA          IN     VARCHAR2,
                          argB          IN     VARCHAR2,
                          o_resultset      OUT resultset_typ);
END pipeline_example;
CREATE OR REPLACE PACKAGE BODY pipeline_example
IS
   FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
      RETURN resultset_typ
   IS
      o_resultset   resultset_typ;
   BEGIN
      OPEN o_resultset FOR
         SELECT colC, colD, colE
           FROM some_table
          WHERE colA = ArgA AND colB = argB;
      RETURN o_resultset;
   END base_query;
   FUNCTION processor (
      p_source_data   IN resultset_typ,
      p_limit_size    IN PLS_INTEGER DEFAULT c_default_limit)
      RETURN table_typ
      PIPELINED
      PARALLEL_ENABLE(PARTITION p_source_data BY ANY)
   IS
      aa_source_data   table_typ;-- := table_typ ();
   BEGIN
      LOOP
         FETCH p_source_data
         BULK COLLECT INTO aa_source_data
         LIMIT p_limit_size;
         EXIT WHEN aa_source_data.COUNT = 0;
         /* Process the batch of (p_limit_size) records... */
         FOR i IN 1 .. aa_source_data.COUNT
         LOOP
            PIPE ROW (aa_source_data (i));
         END LOOP;
      END LOOP;
      CLOSE p_source_data;
      RETURN;
   END processor;
   PROCEDURE with_pipeline (argA          IN     VARCHAR2,
                            argB          IN     VARCHAR2,
                            o_resultset      OUT resultset_typ)
   IS
   BEGIN
      OPEN o_resultset FOR
           SELECT /*+ PARALLEL(t, 5) */ colC,
                  SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
                  SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
                  SUM (CASE WHEN colD = colE AND colD != '0' THEN '1' END) de_one,
                  SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
             FROM TABLE (processor (base_query (argA, argB),100)) t
         GROUP BY colC
         ORDER BY colC
   END with_pipeline;
   PROCEDURE no_pipeline (argA          IN     VARCHAR2,
                          argB          IN     VARCHAR2,
                          o_resultset      OUT resultset_typ)
   IS
   BEGIN
      OPEN o_resultset FOR
           SELECT colC,
                  SUM (CASE WHEN colD > colE AND colE  != '0' THEN colD / ColE END)de,
                  SUM (CASE WHEN colE > colD AND colD  != '0' THEN colE / ColD END)ed,
                  SUM (CASE WHEN colD = colE AND colD  != '0' THEN 1 END) de_one,
                  SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
             FROM (SELECT colC, colD, colE
                     FROM some_table
                    WHERE colA = ArgA AND colB = argB)
         GROUP BY colC
         ORDER BY colC;
   END no_pipeline;
END pipeline_example;
ALTER PACKAGE pipeline_example COMPILE;Edited by: Earthlink on Nov 14, 2010 9:47 AM
Edited by: Earthlink on Nov 14, 2010 11:31 AM
Edited by: Earthlink on Nov 14, 2010 11:32 AM
Edited by: Earthlink on Nov 20, 2010 12:04 PM
Edited by: Earthlink on Nov 20, 2010 12:54 PM

Answer 1

Earthlink wrote:
Contrary to my understanding, the <font face="courier">with_pipeline</font> procedure runs 6 time slower than the legacy <font face="courier">no_pipeline</font> procedure. Am I missing something? Well, we're missing a lot here.
Like:
- a database version
- how did you test
- what data do you have, how is it distributed, indexed
and so on.
If you want to find out what's going on then use a TRACE with wait events.
All nessecary steps are explained in these threads:
HOW TO: Post a SQL statement tuning request - template posting
http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
Another nice one is RUNSTATS:
http://asktom.oracle.com/pls/asktom/ASKTOM.download_file?p_file=6551378329289980701