On Sat, Apr 26, 2014 at 11:20:56AM -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.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 <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
