Re: Decrease MAX_BACKENDS to 2^16

On Sat, Apr 26, 2014 at 11:20:56AM -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-04-26 11:52:44 +0100, Greg Stark wrote:
> >> But I don't think it's beyond the realm of possibility
> >> that we'll reduce the overhead in the future with an eye to being able
> >> to do that. Is it that helpful that it's worth baking in more
> >> dependencies on that limitation?
>
> > What I think it's necessary for is at least:
>
> > * Move the buffer content lock inline into to the buffer descriptor,
> > while still fitting into one cacheline.
> > * lockless/atomic Pin/Unpin Buffer.
>
> TBH, that argument seems darn weak, not to mention probably applicable
> only to current-vintage Intel chips. And you have not proven that
> narrowing the backend ID is necessary to either goal, even if we
> accepted that these goals were that important.
>
> While I agree with you that it seems somewhat unlikely we'd ever get
> past 2^16 backends, these arguments are not nearly good enough to
> justify a hard-wired limitation.

Rather than hard-wiring one, could we do something clever with
bit-stuffing, or would that tank performance in some terrible ways?

I know we allow for gigantic numbers of backend connections, but I've
never found a win for >2x the number of cores in the box, which at
least in my experience so far tops out in the 8-bit (in extreme cases
unsigned 8-bit) range.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate