I haven’t changed the order of statements – I’ve simply moved from a ‘create index’/'add constraint’ to ‘create constraint’.

However, my “instinctive” reading of the statement:

alter table add constraint parallel N

was that the operation of adding the constraint (which implicitly means the creation of the index) should be parallelised: hence my surprise that the table became parallel whilst the index did not.

In fact, the statement is a shorthand for the pair of statements:

alter table add constraint;
alter table parallel (degree N);


Creating the index as parallel 3 means you will get 6 PX slaves running, where the “top” three will each create an index on one-third of the data in its own data segment.

This separation of work means you could typically allocate an average of half an extent per slave more than you really need for the index – with a minimum of 3 extents allocated for the index.

In some versions of Oracle there were various features (sometimes bugs) relating to how Oracle tried to trim extents rather than putting the excess space into the index’s free lists.

The fact that the parallelism used for the table is not applied to the index, it’s a good for me (different parallelism for index and table…why not?).

I find very strange (=a bug) that the statements order you used can change how the optimizer work.

Another question: are there differences in creating and index, then do a “alter index parallel 3″ and a “create index parallel 3″?

I think yes. I saw this with tables, creating an object as “natively” parallel require also a different space allocation (i.e more sparse)