Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers