This is 100% bullshit and you (should) know it. You tout yourself as some sort of RDBMS person, but you come across as knowing absolutely nothing.

At the end of the day, Firebird, Postgres and Mysql all really only support one index type (or variant): b-tree. No matter where your data is presently (index or ram), you will ALWAYS pay a price for insert, and ALWAYS pay a price for select. Now, the number of i/os required for a btree seek is a very attractive equation for anything under the 10s or even hundreds of millions mark. If you're using a quote "standard server", it's exceeding that, or having to write where things _really_ start to suffer. Couple that with that foreign keys, which usually have a btree as well, and all your combinatorial indexes, and you're fucked with any reasonable large data set. There is no disagreement here, unless you suggest that btrees are infintely fast, or that postgres does indeed have a better index (It does have hash, but it's a piece of shit).

If you want to know more, I suggest you investigate the CAP theorem and apply some critical thinking skills to the age old question - given these tradeoffs and relationships and my tolerance to any given one, what is the best tool for the job?

English is hardly an exact business (read: language). Maybe you are suggesting we just remove duplication definitions from dictionaries? We could also remove opposites and adjectives, replacing them with double- and un-!

I was thinking it could grip it by the husk.

Matched, and the only sony device I have is an alarm clock!

Ubuntu & Firefox here, no clipping on the left. Looks just fine. Might be resolution - I'm 1920x1080.

Posting from my rooted nook color.

Seriously, with the native book app installed, plus the kindle app and angry birds. This is some of the best$ 250 I've ever spent.
Ps:
You pay tax b&n books, but not on amazons.

Agreed. I think code is _much_ easier to read, understand and work with if it's always the exact same syntax, tabbing/spacing/commas, etc(I suppose the fact that almost every software project has style guidelines lends credence to this). For this sort of stuff, especially harder (ORM generated or handwritten) queries, I use a very niche program named sqlinform that does an amazing job at putting queries into "your" style. When I do cleanups, the queries usually go from indecipherable to easily understandable. It by default uc'd the keywords, which I never did before but now I find it quite a bit easier to work with.

I'm not affiliated with the software/author, but I'm continually impressed how just how bizarre this software's functions are, yet how useful it is.

It may be an oxymoron in the RDBMS world. In the distributed world, it's par for the course - in fact, it has its own letter in CAP.

They're also still missing 99% of the subquery optimizations they had in the 6.0 Alpha codebase and 99% of the other improvements. When they went sun they started worrying too much about BC and improvements slowed down substantially. In my opinion, if you want less buggy software on a faster release model, you need to not give priority to BC. But then you lose the support contracts, which is all sun cares about.

Unless it's some extreme niche where the shaved cycles really pay off over some time, it seems like a gigantic waste of time for 5%-15% here and there. When you use precompiled, you're already looking at diminishing returns WRT compiling performance, but when you're spending your time compiling everything for that extra 3%, it seems pretty ridiculous. A fraction of that time could be spent flipping burgers to get enough dough to secure yourself a nice SSD which would make totally irrelevant any 1%-5% boosts. In fact, you might even get to finish up on the computer earlier, and go have some beers with your newfound supply of money and time.

I saw you try to sneak that one in there. Haha, nice try!

They don't support DVDs, but you can do hard drives (USB2/eSATA).

http://aws.amazon.com/importexport/

(Originally replied to wrong poster, now modified to prevent "This exact comment has already been posted. Try to be more original... ")
It's extremely unfair to link to the print version of that article. Anand put an immense amount of time into that (and everything before it!) and scarred quite a few bridges to bring it to light for his readers - there are very, very few reviewers out there that would do that for their readerbase. The least you could do is offer him and his site _some_ respect.