Which is fast bulk delete or id's in a table and a where exists ....?

Question

I have some parent objects and that I use bulk collect with fetch limit and I currently store the primary keys of these parent objects to identify their child objects later by using where exists with a correlated subquery.
I'm essentially moving objects graphs that span partitions from table to table.
when I've done my SQL insert into select... I eventually do a delete.
currently the delete uses the parent objects in this working table to identify the children to delete later.
Q. What is likely to be faster?
using a "temporary" table to requery for child objects based on the parents that I have for each batch or
using returning clause from my insert into select so that I have rowid's or primary keys to work with later on
when I want to perform my delete operation?
I essentially have A's that have child B's which in tern have child C's.
I store a batch of A pk's in a table and use those to identify the B's
currently I don't store the B's pk but use the A pk's again to identify the B's which in turn are used to identify the C's later.
I'm thinking if I remember the pk's I'm using at each level I can then use those later when it comes to the deletes.
typically that's done in a returning clause and using a bulk delete from that collection later.
thoughts?

Answer 1

Parallel DML is one option. Another is to ceate a procedure (or package) that does a discreet unit of work (e.g. process parent and its children as a single business transaction). And then write a "+thread manager+" that runs x number copies of these at the same time (via DBMS_JOB for example).
Let's say the procedure's signature is as follows:
create or replace procedure ProcessFamily( parentID number ) is ..
--// processes a family (parent and children)
..Using DBMS_JOB is pretty easy - when you start a job you get a job number for it. Looking at USER_JOBS will tell you whether that job is still in the job queue, or has completed (once off jobs are removed from the queue). The core of the this code will be a loop that checks how many jobs (threads) are running, and if less than the ceiling (e.g. it may only use 20 threads), start more ProcessFamily jobs.
If the total number of threads/jobs to execute are known up front, then this ThreadManager can manually create a long operation entry. Such an entry contains the number of unit of works to do and then is updated with the number of units done thus far. Oracle provides time estimates for completion and percentage progress. This long operation can be tracked by most Oracle-based monitoring software and provide visibility as to what the progress is of the processing.
The ProcessFamly procedure can also use parallel DML (if that makes sense). Or bulk processing (if needed). This approach is also scalable as h/w increases (server upgrades, new server h/w), so too does your ability to run more threads (aka jobs) at the same time.
Now I'm not suggesting that you write a ProcessFamily() proc - I do not know the actual data and problem you're trying to solve. What I'm trying to convey is the basic principle for writing multi-thread/parallel processing software using PL/SQL. And it is not that complex. The critical thing is simply that the parallel procedure or thread be entirely thread safe - meaning that multiple copies of the same code can be started and these copies will not cause serialisation, dead locking, and other (application designed) problems.