3 ms·
This actually doesn't solve the underlying issue that I'm referencing. While this lets you share a pool between multiple processes it does not change the high m
by thdxr 6y ago
This actually doesn't solve the underlying issue that I'm referencing. While this lets you share a pool between multiple processes it does not change the high memory requirements on Postgres to support a highly concurrent workload. One connection (10mb) still can only be doing one thing at a time. Most of the lifetime of a request the connection is idle but locked
- ldng 6y agoOne connection is not actually 10 MB. There is great article explaining the difference, in Linux, beetween reported memory usage and real physical actual usage. I'll edit if manage to find it. Edit: anarazel actually posted it in its reply.
- vorpalhex 6y agoThat might of been a serious problem in 1995, but certainly throwing 64-128gb of ram at a postgres box isn't that uncommon? I'm also curious how you got 10mb per connection (if I'm reading your parenthetical correctly). I've seen a PG box with a few hundred active connections sitting happily at just a gig of ram. Obviously WHAT you do with those connections may well change that but that isn't pg-wire overhead.
- user5994461 6y agoIt's uncommon to throw 128 GB at a postgres. Remember that the world has moved to the cloud, where you pay a hefty fee per GB. It's entirely possible to throw gigabytes of RAM as long as the company is willing to foot the bill. You're going into thousands of dollars per month depending how big and how many replicas we're talking about.