> > Some light weight multi-threaded proxy that relays active
> > connections to the backend and holds idle connections more
> > efficiently than PostgreSQL...
>
> What excuse is there for postgres connections being heavyweight to
> begin with? The only real resource they ought to represent is a
> single TCP connection. Servers that manage 10,000 TCP connections
> are a dime a dozen these days.
>
> Any database context that has to be stored for the connection, the
> state of binary/text or autocommit mode or whatever, will have to be
> maintained by any pooling interface anyways. And I think both of
> those examples are now much cleaner more or less stateless
> per-request flags anyways.
>
> Basically what I'm asking is, hypothetically, if postgres were
> implemented using threads instead of processes, are there any
> per-connection resources that really couldn't be completely disposed
> of when the connection was completely idle between (ie at the start
> of) transactions?
>
> Ideally if every per-connection resource could be completely
> disposed of whenever the connection was completely idle then you
> wouldn't need a whole extra layer for the communication to traverse
> and a whole extra layer of complexity for the protocol semantics to
> be maintained. A multithreaded server could easily handle 10k-40k
> mostly idle connections without any unusual resource needs.
PostgreSQL will never be single proc, multi-threaded, and I don't
think it should be for reliability's sake. See my above post,
however, as I think I may have a better way to handle "lots of
connections" without using threads. -sc
--
Sean Chittenden
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
