Using a ton of thread local variables may be a useful stepping stone, but if we want to be able to separate threads/processes from sessions eventually then I guess we'll want to model sessions as first class objects and pass them around explicitly or using a single TLS variable current_session.
Yep.
This is the real reason I'm excited by the idea of a threading conversion.
PostgreSQL's architecture conflates "connection", "session" and "executor" into one somewhat muddled mess. I'd love to be able to untangle that to the point where we can pool executors amongst active queries, while retaining idle sessions' state properly even while they're in a transaction.
Yeah, that's a long way off, but it'd be a whole lot more practical if we didn't have to serialize and deserialize the entire session state to do it.
