why do you use explicit subquery factoring materialization in this case? I see no obvious reasons for doing this in your case; actually, IMO subquery factoring should be avoided in production-like code (if possible).

It’s also good to note the 11gR2 out-of-the-box new feature for tasks parallelization – DBMS_PARALLEL_EXECUTE. I haven’t used it yet, but it looks nice and neat.

Ideally I think you’d want a trigger on seg$ which is kept up to date with the current number of extents in a segment – but you can’t create triggers on SYS objects. So maybe you could do something with a log miner session that kept looking for changes to seg$ instead. Access to dba_extents by way of a segment ID is (I think) one of the efficient access paths, so if you saw a segment change you may than have the option for keeping your flat copy in synch fairly efficiently.

Investigation (or alternative ideas) left as exercise for interested readers.