> I guess it also works that if your index is parallel but the table not > partitioned then the query will serialize. Though, I have seen parallel fast > full index scans on non-partitioned tables. Would this also be because of Yep, fast full index scans and bitmap fast full index scans can easily be parallelized on non-partitioned indexes (it's not important whether the table itself is partitioned or not, index properties are) > the indexes created in parallel? Figures with oracle there is always a > tradeoff. Create indexes in parallel saves a massive amount of time but then > you have to alter them noparallel. You can rebuild your indexes with parallel and alter them back to noparallel afterwards: SQL> create index i on t(a) parallel; Index created. SQL> select degree from user_indexes where index_name = 'I'; DEGREE ---------------------------------------- DEFAULT 1 row selected. SQL> alter index i rebuild parallel 2; Index altered. SQL> select degree from user_indexes where index_name = 'I'; DEGREE ---------------------------------------- 2 1 row selected. SQL> alter index i rebuild noparallel; Index altered. SQL> select degree from user_indexes where index_name = 'I'; DEGREE ---------------------------------------- 1 1 row selected. Tanel. ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------