On 12/6/16 6:19 PM, Tom Lane wrote:
I'm kind of mystified how a simple code restructuring could solve the
fundamental problems with a large number of backends. It sounds like
what you're describing would just push the problem around, you would
end up with some other maximum instead, max_backends, or
max_active_backends, or something like that with the same problems.
What it sounds like to me is building a connection pooler into the
backend.  I'm not really convinced we ought to go there.

The way I'm picturing it backends would no longer be directly tied to connections. The code that directly handles connections would grab an available backend when a statement actually came in (and certainly it'd need to worry about transactions and session GUCs).

So in a way it's like a pooler, except it'd be able to do things that poolers simply can't (like safely switch the user the backend is using).

I think there might be other uses as well, since there's several other places where we need something that's kind-of like a backend, but if Heikki's work radically shifts the expense of running many thousands of backends then it's probably not worth doing.
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to