In this case the process is spending too much time waiting for database interactions to complete and change of priority cannot change that behaviour. But if it hadn't been that it would have been some other I/O activity.

Finally, on unix, 20 or more is equivalent to 19, which is the maximum-valued i.e. lowest priority.

I know programs don't slow down to be awkward but they do slow down if another process with a higher priority is hogging the cpu.

In a way, but perhaps its more accurate to think of priority as a last resort scheduling mechanism. A computer system has one or more processors each of which has only one program counter (the register that holds the address of the next instruction to be executed). Execution (=occupation of the program counter) will continue for a time slice, at which point another process is allowed in. But these days processes are likely to be waiting on I/O far more often than they are occupying memory, in which case they let other processes have their turn at a slice and are unlikely to block another process even for one turn. So in practice, it is extremely unlikely that a process will hog the CPU, unless either it is erroneously looping, which should not in any case be solved by adjusting priorities, or unless the system is truly saturated with many demanding processes, in which case only a system administrator can affect things with a negative (realtime) priority and of course he shouldn't do so, because slowing a host of processes for the sake of just one is unlikely to be desirable.

Thus, what I am saying is that from a development/support perspective, process priority should also be about the last place to look for the problem.

One world, one people