An early look at Postgres 14: Performance and monitoring Improvements

Re:An early look at Postgres 14: Performance and monitoring ... by megous on Saturday May 22, 2021 @08:28PM (#27251458)

Personally I don't expect this to be ever improved in PostgreSQL (ie. change from process per connection model to something else), so I design my multi-user apps so that everything works fine with session pooling (quick short sessions/connections to pgbouncer) and connections that wait for NOTIFY get made directly to postgresql server, and are also limited in number.

And it works fine on low-resourced machines that I tend to use for everything.

[ Parent | on HN ]

Re:An early look at Postgres 14: Performance and monitoring ... by Diggsey on Saturday May 22, 2021 @09:05PM (#27251624)

Switching to a threaded model would be a lot of work, but there is a simpler solution that retains most of the benefits: using a process-per-connection model for active connections only, and allowing a single process to have multiple idle connections.

I follow the mailing list because I'm interested in this exact issue. Konstantin Knizhnik sent a patch implementing a built-in connection pooler in early 2019 that uses a similar approach to what I just described. The work on that has continued to this day, and I'm hopeful that it will eventually be merged.

[ Parent | on HN ]

Re:An early look at Postgres 14: Performance and monitoring ... by megous on Saturday May 22, 2021 @09:17PM (#27251674)

But how's that different from pgbouncer?

EDIT: I see, it would have session state restore, not just DISCARD like pgbouncer.

[ Parent | on HN ]