On Wed, Dec 7, 2016 at 12:36 AM, Jim Nasby <jim.na...@bluetreble.com> wrote:
> 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). If we're going to consider that, I think we should consider going all the way to the technique used by many (most?) database products, which is to have a configurable number of "engines" that pull work requests from queues. We might have one queue for disk writes, one for disk reads, one for network writes, etc. Traditionally, each engine spins over attempts to read from the queues until it finds a request to process; blocking only if several passes over all queues come up empty. It is often possible to bind each engine to a particular core. Current process-local state would be passed around, attached to queued requests, in a structure associated with the connection. I don't know how that execution model would compare to what we use now in terms of performance, but its popularity makes it hard to ignore as something to consider. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
