From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Decrease MAX_BACKENDS to 2^16 |
Date: | 2014-04-28 09:39:09 |
Message-ID: | 20140428093909.GD2815@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Abhijit Menon-Sen | 2014-04-28 10:15:19 | allowing VACUUM to be cancelled for conflicting locks |
Previous Message | Andres Freund | 2014-04-28 09:32:31 | Re: Composite Datums containing toasted fields are a bad idea(?) |