What is the benifit of Pipe function

Question

Hi,
I agree that piping function return some set of rows when it is ready.
But if my main query where clause is using the piping function for filter like below
select p_name a1, p_add a2 from tname, tadd where tname.id = tadd.id and tname in (select * from table(pipe_fun_return_some_names));
Now my question is "using pipe function will my main query starts executing without waiting all data return by pipe function"
If yes then how my main query gets executed.
If No how can then will it cost me performance point of view.
so shell using piping function like this improve performance of my sql.
or simply can i use a table type and object to query ---
select p_name a1, p_add a2 from tname, tadd where tname.id = tadd.id and tname in (select * from table(table_fun_return_some_names));
Thanks Gurus...

Answer 1

Ora_Is_Not_Magic wrote:
Hi,
I agree that piping function return some set of rows when it is ready.
But if my main query where clause is using the piping function for filter like below
select p_name a1, p_add a2 from tname, tadd where tname.id = tadd.id and tname in (select * from table(pipe_fun_return_some_names));
Now my question is "using pipe function will my main query starts executing without waiting all data return by pipe function"
If yes then how my main query gets executed.
If No how can then will it cost me performance point of view.Do you mean something along the lines that, if the value is found in the subquery (pipeline function) results early on it will return the main query data quicker than if the value is found later on in the subquery (pipeline function) results?
SQL> create or replace type t_nums as table of number;
  2  /
Type created.
SQL> ed
Wrote file afiedt.buf
  1  create or replace function f_pipe_asc return t_nums pipelined as
  2  begin
  3    for i in 1..1000000
  4    loop
  5      pipe row(i);
  6    end loop;
  7    return;
  8* end;
SQL> /
Function created.
SQL> ed
Wrote file afiedt.buf
  1  create or replace function f_pipe_desc return t_nums pipelined as
  2  begin
  3    for i in 1..1000000
  4    loop
  5      pipe row(1000001-i);
  6    end loop;
  7    return;
  8* end;
SQL> /
Function created.
SQL> @c:\statson
SQL> select 1 from dual where 1 in (select * from table(f_pipe_asc()));
         1
         1
Elapsed: 00:00:00.29
Execution Plan
Plan hash value: 4199234228
| Id  | Operation                            | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                     |            |    82 |       |    28   (8)| 00:00:01 |
|   1 |  NESTED LOOPS                        |            |    82 |       |    28   (8)| 00:00:01 |
|   2 |   FAST DUAL                          |            |     1 |       |     2   (0)| 00:00:01 |
|   3 |   VIEW                               | VW_NSO_1   |    82 |       |    26   (8)| 00:00:01 |
|   4 |    SORT UNIQUE                       |            |    82 |   164 |    26   (8)| 00:00:01 |
|*  5 |     COLLECTION ITERATOR PICKLER FETCH| F_PIPE_ASC |       |       |            |          |
Predicate Information (identified by operation id):
   5 - filter(VALUE(KOKBF$)=1)
Statistics
        100  recursive calls
          0  db block gets
         88  consistent gets
          0  physical reads
        116  redo size
        404  bytes sent via SQL*Net to client
        396  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
          1  rows processed
SQL> select 1 from dual where 1 in (select * from table(f_pipe_desc()));
         1
         1
Elapsed: 00:00:00.31
Execution Plan
Plan hash value: 2978834354
| Id  | Operation                            | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                     |             |    82 |       |    28   (8)| 00:00:01 |
|   1 |  NESTED LOOPS                        |             |    82 |       |    28   (8)| 00:00:01 |
|   2 |   FAST DUAL                          |             |     1 |       |     2   (0)| 00:00:01 |
|   3 |   VIEW                               | VW_NSO_1    |    82 |       |    26   (8)| 00:00:01 |
|   4 |    SORT UNIQUE                       |             |    82 |   164 |    26   (8)| 00:00:01 |
|*  5 |     COLLECTION ITERATOR PICKLER FETCH| F_PIPE_DESC |       |       |            |          |
Predicate Information (identified by operation id):
   5 - filter(VALUE(KOKBF$)=1)
Statistics
         28  recursive calls
          0  db block gets
         48  consistent gets
          0  physical reads
          0  redo size
        404  bytes sent via SQL*Net to client
        396  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          1  rows processed
SQL>I don't have your data to test, but I'm guessing the fact the optimiser is doing a SORT UNIQUE on the pipeline results in order to perform the "IN", it's going to take the same amount of time whether the required value is the first out of the pipeline results or the last.