Index construction is an I/O-intensive task, not generally CPU-bound. It's also likely to involve locks on table extents, and is therefore not amenable to multiprocessing (INDEX requests to a single table in multiple sessions are likely to contend with one another).
Similarly, multiple INDEX requests on different tables in a single datafile are likely to saturate the I/O device channel (causing contention, and slowing overall throughput). If you have enough disk speed for simultaneous INDEX requests on a single device, the likely result is extent fragmentation, which will burden all future queries with ingrained inefficiency.
If you have a large table which has been partitioned onto multiple independent devices, and have configured appropriate parallelism, then the database itself will handle an INDEX request as efficiently as possible, and you're better off getting out of the way and letting it do its job.
As a general rule, attempting to force indexing to finish more quickly than the hardware supports only results in less efficient data storage and overall slower performance. The details for optimizing database configuration are RDBMS-specific, and more a matter for Database Administrators or vendor-specific forums, but if you are not using the fastest (most expensive) devices you can afford, that is a logical starting point.