Yes, you still missing something, and that is that Windows does not work like you think it works.
1. Priority changes set the base priority of your process, and Windows can and does dynamically adjust this as it goes, boosting it up for your process when needed, and dropping it back down over time as your process completes each time-slice (but never lowering back past the base you set). You can specify priority levels from 0 to 15 (assuming you set your thread priority at the same time) - Windows' actual priorities can range from 0 to 31.
2. Higher priorities give processes a better chance to run when they are ready to run, ie it doesn't determine how fast they run, but how often they get chosen to run. A single non-threaded process running flat out cannot run faster with a higher priority on a multi-core system. The most it can use is 1 single-cores worth of processing, no matter what priority you set it at. Only if you are multi-threading or have multiple cooperating processes can you have more than 1 cores worth of processing power being used at one time.
3. On a multi-core system, Windows will tend to schedule your DBPro task onto a single core, and move all other processes to other cores anyway. You can see this and prove it to yourself in Task Manager under the Performance tab.
In summary, for a single-threaded single process:
Single-core system - you have to cooperate with the OS (keyboard/mouse/file IO etc), so don't change the priority - if you do, then you may adversely affect the system, and Windows will eventually drop your priority for you and raise the priority of other processes giving a net result of no change.
Multi-core system - Windows will tend to give your DBPro process its own core, so you don't need to change the priority - if you do then you'll get, at most, a dedicated core which you probably had anyway.
Basically, you don't need to change your process priority - better method and algorithms are how you make you code run faster.
