On 2014-04-28 10:48:30 +0300, Heikki Linnakangas wrote: > 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.
65k connections will be absolutely *disastrous* for performance because of the big PGPROC et al. I *do* think we have to make live easier for users here by supplying builtin pooling at some point, but that's just a separate feature. > 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. The main reason I want to shrink it is that I want to make pin/unpin buffer lockless and all solutions I can come up with for that require flags to be in the same uint32 as the refcount. For performance it'd be beneficial if usagecount also fits in there. I agree that we can move a good part of BufferDesc into a separately indexed array. io_in_progress_lock, freeNext, wait_backend_id are imo good candidates. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers