6 ms·
Am I the only one eagerly waiting on postgres to transition away from the process per connection model? It seems like that is the only glaring con for postgres
by kcolford 6y ago
Am I the only one eagerly waiting on postgres to transition away from the process per connection model? It seems like that is the only glaring con for postgres compared to SQL server. This would really put the nail in coffin for MySQL and other alternatives.
- ComodoHacker 6y agoWhat's so wrong with that model?
- ComputerGuru 6y agoIt doesn’t scale and makes some abstractions more difficult.
- claytonjy 6y agohow about pgBouncer for connection pooling? I know it's more operational overhead, but is that still not good enough for your use case?
- ComodoHacker 6y agoHow far does it need to scale? Times of two-tier apps are gone, middle tier has it's own pooling.
- pgaddict 6y agoIdeally thousands (and maybe even tens of thousands) of connections. At the moment we're quite far from that, as the benchmarks in the thread [1] demonstrate (low hundreds, I'd say). There's an awful lot of applications designed with the idea that connections are cheap. And on some databases it's actually true. But it's also about hardware - machines with hundreds of cores are getting quite common, applications have "think time" so you need to use a multiple of core count to saturate the CPU, etc. Currently the limit is probably "low hundreds" depending on the workload (the shorter/cheaper the transactions, the worse). Connection pools are great, but unfortunately not really a universal solution. [1] https://www.postgresql.org/message-id/flat/20200301083601.ews6hz5dduc3w2se%40alap3.anarazel.de https://www.postgresql.org/message-id/flat/20200301083601.ew...
- jeffdavis 6y agoI expect there will be other changes to improve connection scaling first.
- fabian2k 6y agoThere is a proposed change that improves connection scaling signficantly: https://www.postgresql.org/message-id/flat/20200301083601.ews6hz5dduc3w2se%40alap3.anarazel.de https://www.postgresql.org/message-id/flat/20200301083601.ew... This should be either in Postgres 13 or 14, not sure how they decided in the end.
- ksec 6y agoStrange, they really wanted it for 13 and allowed it to be committed post feature freeze, but then all discussions stopped after April. And I couldn't find anything else in the mailing list.
- pgaddict 6y agoThere was a long discussion about multiple patches that "almost made it" on an internal release list. Ultimately, the conclusion was not to push them after the code freeze date (which was already extended by a week). Obviously, it'd be great to get those patches in, but there's always the risk of pushing something that may not be quite ready yet, did not go through sufficient review etc. Which might disrupt the whole release schedule, make the stabilization phase longer, etc. And all the lockdowns around the world just amplify the risk. There's also the question whether it's worth breaking the rules the project adopted over the years. Considering all this, it probably makes sense to leave this for v14 ... But yeah, it'd be great to have this in v13, had it been ready before the code freeze.
- ksec 6y agoThanks. At least we know it should be coming in PG 14. Hopefully Zheap too.
- jkatz05 6y agoThis earliest this will be available is PostgreSQL 14; it was not added to PostgreSQL 13.