Re: Fwd: sensible configuration of max_connections

On Fri, Feb 7, 2020 at 11:14 AM Justin <zzzzz(dot)graf(at)gmail(dot)com> wrote:

>
> On Fri, Feb 7, 2020 at 1:56 PM Sam Gendler <sgendler(at)ideasculptor(dot)com>
> wrote:
>
>> 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.