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:
http://www.postgresql.org/mailpref/pgsql-hackers
