Comment: Re:Industry wants more users to use products (Score 1) 168
Comment: Re:Yup (Score 1) 112
Comment: Yup (Score 3, Funny) 112
Splashtop's Cliff Miller Talks About Their New Linux App (Video) 96
from the around-the-corner-or-around-the-world-is-all-the-same-to-me dept.
Comment: Thank fuck! (Score 5, Funny) 217
Comment: Seriously? (Score 1) 118
Would Charles Darwin Have Made a Good Congressman? 155
from the descent-by-natural-election dept.
Comment: Oh, now it makes sense (Score 1, Insightful) 163
" for a (highly negotiable) fee"
Oh, now I see. As you were.
Comment: Re:Did the cop got fired? (Score 5, Insightful) 451
Scientists Who Failed to Warn of Quake Found Guilty of Manslaughter 459
from the well-that-sounds-productive dept.
Ubuntu 12.10 Quantal Quetzal Out Now; Raring Ringtail In the Works 318
from the that-alphabet-song-really-gets-in-your-head dept.
Comment: Re:That's great and all, but . . . (Score 3, Informative) 146
While Postgresql does use the Apache model, there is middleware available (google 'pgpool' for an example) that amongst other things will queue requests so they can be serviced by a limited number of children. Of course this only matters if there are an awful lot of simultaneous queries (without the corresponding amount of server RAM).
However; your claim about threads per CPU is oversimplified, and especially wrong with a DB server where processes will most likely be IO bound. With 1 core, for example, there is nothing wrong with having 5 processes parsing and planning a query for a few microseconds, while the 6th is monopolising IO actually retrieving query results. Or the reverse - having 1 CPU-bound process occasionally being interrupted to service 5 IO bound processes, which would negligibly impact the CPU-bound query, while hugely improving latency on the IO bound queries.
Comment: Re:That's great and all, but . . . (Score 3, Informative) 146
Want to Change the Slashdot Logo? For 1 Day in October, You Can 128
from the small-canvas-for-big-ideas dept.