The Brave New World I've been talking about makes high normal form database centric applications all the more appropriate. I know of at least two extant applications which implement this way. That said, the issue remains: what will the interTubes infrastructure look like in two years and further, and what sort of RDBMS architecture best exploits it? It's worth noting that there is precedent; Bill Gates got very rich by targeting software to not yet available hardware. That said, some comments on some comments.
[Chris]: [Robert asserts] threads are more efficient, processor-power-wise to spin up than processes, and therefore if you insist on a single-threaded multi-process model, you can't have sufficient performance to make your database system relevant.
No, that's not exactly what I said. The issue is lost cycles as one moves down to a single thread. It's more about the number of clients that can be supported "simultaneously". At one time I was also enamoured of thread count to execute queries in parallel; not so much now. For reporting generally, and BI/DW specifically, sure. But for OLTP, where my interest lies, not so much. There, client count is what matters. Clients run relatively discrete transactions on few rows; parallelism isn't much help for that sort of client. Yes, to some extent I've changed my mind.
Think of the issue this way: if it were true that scaling down threads to one per processor/core yielded a scale up in performance equivalently (only one of two threads yields twice the performance on that last thread), then the question gets more difficult. But threads and cores don't scale that way. Such reverse scaling could only happen if the core's frequency increased as the inverse of threads active. That just doesn't happen, you get a bin or two; that nasty frequency brick wall is the reason vendors have turned to multi-core and threads in the first place.
It's a matter of relative performance, not absolute. If the PG developers decide to not implement a threaded engine (some or all sub-systems), PG will inevitably be viewed as not worth the cost. I never said that this would happen tomorrow. Threading isn't a fad, but a hardware evolution. As the quote from Intel states, that's where they intend to go. Countering that is the massively parallel single thread/core machine, such as the Transputer or Thinking Machine or possibly an armada of ARM (which has been reported to be adding threaded cpu to its menu) cores on a chip. Whether a *nix could better manage such a machine (as opposed to a threaded one) is up in the air; experience from the 1980's when parallel machines were all the rage suggests not (Amdahl's Law put an end to them, and is still in effect). Some feel that the ARM armada will take down Intel. Way too early to bet on that. Couple that with the rapidly evolving web infrastructure, and we have a Brave New World where the interTubes is virtual RS-232 passed on virtual Cat-5; what's on the client end of the wire is just a terminal, prettily pixelated nevertheless only a terminal. That evolution matters to how a RDBMS (and its applications) is optimally architected.
Intel needed MicroSoft to bloat up its software in order to create demand for ever higher cycle count chips; it's the Wintel Monopoly for a reason. Now that frequency is near a brick wall, clients are devolving from PCs to wrist computers and such, the likes of Intel can't count on Office to justify new chips (unless Steve's boys and girls can parallelize Office; I don't see goods odds on that). Servers are pathologically multi-user, and therefore the logical vein to mine. That's what's happening and will continue.
[Chris}: Instead things like network connection/teardown, command parsing, and, well, actual work dwarf process/thread startup cycles by several orders of magnitude.
As I've said before, the main issue isn't process startup cycles versus thread, but all those cycles lost by running single threaded, which could be used for actual work. All that network stuff gets kicked to the curb in the Brave New World anyway; that's a large measure of the point. And, as above, the issue isn't just "startup cycles", but total processing cycles doing useful work. Throw away all but one thread, and you throw away nearly (threads - 1 + (bin bump))/threads of useful work. See this testing. That's the issue. They No Such Thing As A Free Lunch, and the cpu is about the most significant example.
Which is precisely why client multi-plexing is superior; with a threaded engine, you get twice (or more) active clients without the falderal. The comment on connection pooling reveals the same issue: auditability and transaction integrity if nothing else. You end up having to do all that manually, if at all. While connection pools were initially at the database end, they are now most commonly in the web-server, and motivated by the (un)connectedness of HTTP. Web server writers face the same issue as database server writers. When I was building servlet/applet thingees in the late 1990's and early 2000's, we had to build quick and dirty poolers ourselves. By about 2002, databases and web servers had integrated the support. Had to happen. Here's an example for Tomcat. Folks can, and do, argue about which piece of software should own the connection pool; I'll avoid that for now.
What's missing from the comments is discussion of my main point: with a threaded engine working on threaded (and likely with higher thread counts in the future) cpu's, high bandwidth connections, and client multi-plexing; one ends up with a RS-232 like environment. While I haven't explored it, there's an environment named Opa (Wikipedia has a short article), which is said to include web server and database server all in one. That's just begging for a fully connected infrastructure. Ideally, and I haven't explored enough to know as I type, there would be a single "connection", from the client's perspective; Opa takes care of managing the database/web server interaction in a way which preserves transaction semantics and client identity.
The Achilles heel of those *nix/RDBMS/RS-232/VT-X00 applications was the limit on the number of clients that could be accommodated since the client patch remained while the user kept a session. The emerging hardware/infrastructure that I'm discussing may/should remove that restriction. This also means that developers must heed the mantra, "the user doesn't determine transaction scope". With HTTP (un)connectedness, that isn't much of an issue.
With ever lighter clients, database centric (as opposed to coder's wet dream of client centric) applications become far more appropriate. Databases which can support higher client count on a given hardware platform (through threading, that is) will eventually clobber those that can't. That MySql, kind of OS, has threaded engines will make it difficult for other OS databases that don't. The question will not be PG versus Oracle/DB2/SS but PG versus MySql. While that's true today, the performance and configuration differences will only get greater over time.
While I surely agree that writing a threaded server, of any kind, is far more difficult than letting the O/S take care of the details (by writing a process based server), it's clear that the cpu makers are going to threads for performance. Think of this as a game of musical chairs.
 There is this internship listed on their website (typos their's):
Adding support for relational databases in Opa. The Web developping platform Opa has so far concentrated on its own database engine as well as the connection to existing NoSQL databases. The goal of this ambitious internship is to create the fundations of a framework for connecting relational databases to Opa (starting with MySQL). Different levels of integration will be experimented and successively made available (roughly: an untyped low-level API, a dynamically typed API, and a statically typed API generated at compile time). This internship requires excellent skills in functional programming (Ocaml, F#, Haskell, Scala) and a very good knowledge of the SQL language and its concepts.