Most of my transactions are relatively long-running (minutes) and mostly idle, so the db can handle the transaction load. There honestly doesn't seem to be a g

Most of my transactions are relatively long-running (minutes) and mostly idle, so the db can handle the transaction load. There honestly doesn't seem to be a good solution to this problem. I have reorganized my app a bit to try to keep the transactions shorter (mostly checkpointing) but it's using architecture to solve a fundamentally technical problem. I wouldn't have this problem with MySQL. Switching from processes to threads (or some other abstraction) per connection isn't likely to show up in Postgres anytime soon, so I guess I'm willing to live with this... but I'm not going to pretend that Postgres is without some serious downsides.