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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
