Forgot your password?
typodupeerror

Comment: Re:you've got to be kidding me (Score 1) 71

Vim? Joining 10 tables is a ballache in terms of typing, but it's not actually /hard/ - any more than writing a function with 10 statements is hard. You just need to step away from the ORM long enough to realise that actually relational databases are perfectly logical and easy (well, as easy as any other programming) despite what various frameworks have screamed at you for years.

Comment: Re:That's great and all, but . . . (Score 3, Informative) 146

by gazbo (#41298353) Attached to: PostgreSQL 9.2 Out with Greatly Improved Scalability
Well...arguably. This is the exact same argument as Apache vs Nginx, where Apache spawns a child process per client, whereas Nginx has a limited number of worker processes that handle a queue of requests as they become free. Nginx definitely has an advantage in terms of RAM when servicing thousands of (truly) simultaneous requests.

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.

"Atomic batteries to power, turbines to speed." -- Robin, The Boy Wonder

Working...