why would you have to do such a small amount of work in parallel at all??

ops$tkyte@ORA9IR2> create table emp
2 as
3 select id empno, 0 sal
4 from big_table.big_table
5 where rownum <= 500000;

Table created.


ops$tkyte@ORA9IR2> create table emp_sals
2 as
3 select id empno, object_id new_sal
4 from big_table.big_table
5 where rownum <= 500000;

Table created.

ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> alter table emp_sals add constraint emp_sals_pk primary key(empno);

Table altered.

ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> set timing on
ops$tkyte@ORA9IR2> update (select sal, new_sal
2 from emp, emp_sals
3 where emp.empno = emp_sals.empno )
4 set sal = new_sal;

500000 rows updated.

Elapsed: 00:00:33.08
ops$tkyte@ORA9IR2>


that was on a tiny desktop machine, nothing fancy I would not be writing code at all (complex multi-threaded code in particular) to do something that takes seconds to accomplish.


Or, if you feel "parallel must be done", use the database:

ops$tkyte@ORA9IR2> alter table emp parallel 4;
Table altered.

ops$tkyte@ORA9IR2> alter table emp_sals parallel 4;
Table altered.

ops$tkyte@ORA9IR2> alter session enable parallel dml;
Session altered.


Although on my single disk, single cpu system that takes about the same amount of time.



Trying to do this particular thing in your own code by employee id ranges would be not very performant either. You would have 10 things doing a FULL scan of the employee table (either that, or even worse -- 10 RANGE scans of the employee table) and 10 full scans of the employee salary table (or worse, they might use an index) and updating rows next to each other and so on. It would introduce as much contention as you could.


I think a single update is all you need here.