Robert Haas <robertmhaas@gmail.com> writes:
> I think the fact that making 20k connections might crash your computer
> is an artifact of other problems that we really ought to also fix
> (like per-backend memory utilization, and lock contention on various
> global data structures) rather than baking it into more places. In
> PostgreSQL 25.3, perhaps we'll be able to run distributed PostgreSQL
> clusters that can service a million simultaneous connections across
> dozens of physical machines. Then again, there might not be much left
> of our current buffer manager by that point, so maybe what we decide
> right now isn't that relevant.
Yeah. I think that useful use of 64K backends is far enough away that
it shouldn't be a showstopper argument, assuming that we get something
good in return for baking that into bufmgr. What I find much more
worrisome about Andres' proposals is that he seems to be thinking that
there are *no* other changes to the buffer headers on the horizon.
That's untenable. And I don't want to be told that we can't improve
the buffer management algorithms because adding another field would
make the headers not fit in a cacheline. (For the same reason, I'm
pretty unimpressed by the nearby suggestions that it'd be okay to put
very tight limits on the number of bits in the buffer header flags or
the usage count.)
regards, tom lane
