Parallelized CONNECT BY PUMP

Question

Hi All,
Did anyone managed to parallelize CONNECT BY PUMP rowsource and its corresponding join?
I'm thinkging about following steps from execution plan
| Id  | Operation                            | Name              | Rows  | Bytes | Cost (%CPU)| Time  | Pstart| Pstop |
|   5 |   NESTED LOOPS                       |                   |       |       |            |       |  |       |
|   6 |    CONNECT BY PUMP                   |                   |       |       |            |       |  |       |
-------------------------------------------------------------------------------------------------------------------------- Update:
Not solution, but kind of workaround. Maybe someone will find it useful. You can improve performance of CONNECT BY operation on big datasets (milions of rows) by parallelizing source rowset, using NO_CONNECT_BY_FILTERING hint and accessing data with FTS. This way you're parallel HJ, which for me was eight to ten times faster than other methods. BTW, you'll need significant amount of PGA available for this process - I was using manual worarea policy for this.
SQL> ALTER SESSION SET workarea_size_policy=MANUAL;
Session altered.
Elapsed: 00:00:00.00
SQL> ALTER SESSION SET sort_area_size=1073741824;
Session altered.
Elapsed: 00:00:00.00
SQL> INSERT /*+ APPEND */ INTO zzz_t1 SELECT /*+ NO_CONNECT_BY_FILTERING */ * FROM cp1_client StART WITH client_parent_id = 1 CONNECT BY PRIOR client_id = client_parent_id;
1497838 rows created.
Elapsed: 00:00:40.04
| Id  | Operation                                | Name       | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
|   0 | INSERT STATEMENT                         |            |       |       |  2330 (100)|          |       |       |        |      |            |
|   1 |  LOAD AS SELECT                          |            |       |       |            |          |       |       |        |      |            |
|*  2 |   CONNECT BY NO FILTERING WITH START-WITH|            |       |       |            |          |       |       |        |      |            |
|   3 |    PX COORDINATOR                        |            |       |       |            |          |       |       |        |      |            |
|   4 |     PX SEND QC (RANDOM)                  | :TQ10000   |  1497K|   617M|  2330   (2)| 00:00:28 |       |       |  Q1,00 | P->S | QC (RAND)  |
|   5 |      PX BLOCK ITERATOR                   |            |  1497K|   617M|  2330   (2)| 00:00:28 |     1 |    16 |  Q1,00 | PCWC |            |
|*  6 |       MAT_VIEW ACCESS FULL               | CP1_CLIENT |  1497K|   617M|  2330   (2)| 00:00:28 |     1 |    16 |  Q1,00 | PCWP |            |
----------------------------------------------------------------------------------------------------------------------------------------------------Thanks,
Lukasz
Edited by: Łukasz Mastalerz on Mar 26, 2012 2:11 PM

Answer 1

This is new feature of Oracle 9i and above related with hierarchy queries.
Sometimes it leads to peroformance problems. You can use undocumented
parameter oldconnect_by_enabled to get rid of it and return to "old good 8i":
SQL> set autotrace traceonly expl
SQL> select object_id from nc_objects start with object_id = 100
  2  connect by prior object_id = parent_id
  3  /
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=15 Bytes=345)
   1    0   CONNECT BY (WITH FILTERING)
   2    1     NESTED LOOPS
   3    2       INDEX (UNIQUE SCAN) OF 'XPKNC_OBJECTS' (UNIQUE) (Cost=
          2 Card=1 Bytes=12)
   4    2       TABLE ACCESS (BY USER ROWID) OF 'NC_OBJECTS'
   5    1     NESTED LOOPS
   6    5       BUFFER (SORT)
   7    6         CONNECT BY PUMP
   8    5       TABLE ACCESS (BY INDEX ROWID) OF 'NC_OBJECTS' (Cost=6
          Card=15 Bytes=345)
   9    8         INDEX (RANGE SCAN) OF 'XIF25NC_OBJECTS' (NON-UNIQUE)
           (Cost=3 Card=15)
SQL> alter session set "_old_connect_by_enabled" = true;
Session altered.
SQL> select object_id from nc_objects start with object_id = 100
  2  connect by prior object_id = parent_id
  3  /
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=15 Bytes=345
   1    0   CONNECT BY
   2    1     INDEX (UNIQUE SCAN) OF 'XPKNC_OBJECTS' (UNIQUE) (Cost=2
          Card=1 Bytes=12)
   3    1     TABLE ACCESS (BY USER ROWID) OF 'NC_OBJECTS'
   4    1     TABLE ACCESS (BY INDEX ROWID) OF 'NC_OBJECTS' (Cost=6 C
          rd=15 Bytes=345)
   5    4       INDEX (RANGE SCAN) OF 'XIF25NC_OBJECTS' (NON-UNIQUE)
          Cost=3 Card=15)Rgds.