Benchmarks, at the time, showed that performance started to fall off due to contention if the number of processes got much larger. I imagine that the speed of storage today would maybe make 3 or 4x core count a pretty reasonable place to start. There will be a point of diminishing returns somewhere, but you can probably construct your own benchmarks to determine where that point is likely to be for your workload.
I wonder if anyone has run benchmark like that lately? Doing such a benchmark maybe worth while given that so much is now running either in the cloud or running in a VM or some other kind of Container. all this abstraction from the hardware layer surely has had to have an impact on the numbers and rules of thumb...
I still run on real hardware and spinning disk.
To be honest, I don't even know if the old rule of thumb would still apply, given the changes that have likely occurred within the postgresql codebase over the course of a decade. But there were plenty of people benchmarking and writing about how to administer large installations and do performance tuning back then. I don't imagine that they don't exist today, too. They'll probably chime in on this thread soon enough.
A quick amazon search for 'postgresql performance' turns up plenty of books on the topic that address more recent versions of the db. I'd go hit the O'Reilly bookshelf website and use a trial membership to see what they have to say (I generally consider the o'reilly bookshelf, which gives you access to pretty much all books by all technical publishers, to be an invaluable tool and worth every penny). I wouldn't be surprised if the postgresql documentation itself doesn't provide insight as to appropriate numbers, but no one ever reads the manual any longer.
