On 04/26/2014 09:27 PM, Andres Freund wrote:
> I don't think we need to decide this without benchmarks proving the
> benefits. I basically want to know whether somebody has an actual
> usecase - even if I really, really, can't think of one - of setting
> max_connections even remotely that high. If there's something
> fundamental out there that'd make changing the limit impossible, doing
> benchmarks wouldn't be worthwile.
It doesn't seem unreasonable to have a database with tens of thousands
of connections. Sure, performance will suffer, but if the connections
sit idle most of the time so that the total load is low, who cares.
Sure, you could use a connection pooler, but it's even better if you
don't have to.
If there are big gains to be had from limiting the number of
connections, I'm not against it. For the purpose of shrinking BufferDesc
though, I have feeling there might be other lower hanging fruit in
there. For example, wait_backend_pid and freeNext are not used very
often, so they could be moved elsewhere, to a separate array. And buf_id
and the LWLock pointers could be calculated from the memory address of
the struct.
- Heikki
