But I do not think that "memory-bound" is right for most of our processes.

Well, I was only talking about the one process I thought you were describing (extracting a very large volume of data) and I did indicate it was a guess based upon your description, by using the word "probably"; so no biggy.

The thing I was getting at is that XXX-bound: means that performance (measured in wall-time not cpu time) is constrained by XXX. That is:

1. CPU-bound: If you could insert a faster processor -- with nothing else changed -- the process would complete sooner.
2. IO-bound: If you could speed up IO -- with nothing else changed -- the process would complete sooner.
3. Memory-bound: If you added more memory -- with nothing else changed -- the process would complete sooner.

With DB apps (often; not always), things get muddy because: a) they often have bursts of both cpu-intensive & IO-intensive processing; b) often a lot of the cpu-intensive work (searching/selecting/sorting/grouping) is done by a completely different process (the DB engine); often-as-not on a completely different box or even cluster of boxes.

So when trying to categorise the overall processing (rather than the individual process) for a given task; you have to access the complete end-to-end processing requirements of that task.

Often, the client application itself would be considered IO-bound because it spends the greatest proportion of its time waiting for IO from the DB.

But if you consider the overall processing, it might be considered cpu-bound because the IO-rate from the DB is limited by cpu-bound calculations within the DB.

But finally, the overall thing might be memory-bound because the DB engines processing requires it break its cpu-intensive calculation into chunks, because the overall dataset it is processing is greater than can be loaded into its memory.

Bottom line is that the essentially throw-away comment in that other thread, that started this one, are very generic: all else being equal, running M processes, N-at-a-time on an N-core system will be faster than running those same M processes all concurrently; but as I showed above, all-else is very rarely equal.