neilc

Pensions would also be lower if they were invested in funds that made lower or negative returns. The theory (right or wrong) is that the high fees charged by the hedge funds are justified because they provide better risk-adjusted returns than other investment vehicles. Hedge funds may be bad and their CEOs may be overcompensated, but it is more complicated than just "every dollar paid to Kenneth Griffin is a dollar taken from a pension fund."

This is wrong. Postgres uses 8KB blocks for heap data by default, but you can (and typically will) have multiple rows in a single page.

"We constructed a sampling frame and selection process to minimize selection biases and maximize generalizability of the accumulated evidence. Simultaneously, to maintain high quality, within this sampling frame we matched individual replication projects with teams that had relevant interests and expertise. We pursued a quasi-random sample by defining the sampling frame as 2008 articles of three important psychology journals: Psychological Science (PSCI), Journal of Personality and Social Psychology (JPSP), and Journal of Experimental Psychology: Learning, Memory, and Cognition (JEP: LMC)...The first replication teams could select from a pool of the first 20 articles from each journal, starting with the first article published in the first 2008 issue. Project coordinators facilitated matching articles with replication teams by interests and expertise until the remaining articles were difficult to match. If there were still interested teams, then another 10 articles from one or more of the three journals were made available from the sampling frame. Further, project coordinators actively recruited teams from the community with relevant experience for particular articles."

This is not the case.

I think you'd get most of the benefit by writing a static analysis tool (a la "go vet") that suggests when reordering a struct's fields would reduce memory consumption.

http://www.postgresql.org/docs/devel/static/functions-json.h...

That said, if you're doing a lot of mutation of large JSON documents stored in a single Postgres row value, the storage/concurrency control behavior still won't be ideal.

Which professions don't have that property? Not many. Science and writing/art give you a chance for that kind of longevity, I suppose -- although even then, doing something that has any real impact 50+ years later is difficult and very rare.

I don't think this is true, at least not as stated. You should certainly be thinking about more than crash-stop failures, but full-blown Byzantine fault tolerance is rarely warranted in practice. Empirically, the number of systems that use non-Byzantine vs. Byzantine agreement is probably on the order of 100:1.

Sure, but typical MVCC systems that provide SI will serialize transactions in some cases anyway. For example, if two transactions try to update the same row in Postgres, the second will block until the first one commits/aborts. This is true under RC, RR, or SERIALIZABLE.

> This fundamental overhead is a key reason why almost every commodity RDBMS defaults to one of these weaker isolation levels and why databases like Oracle don't support serializable isolation at all.

I don't think that's true: if you already have an MVCC implementation that provides SI, the additional overhead of providing SSI is relatively modest. I'd say the main reason Oracle doesn't provide SERIALIZABLE is historical: their MVCC implementation predated Cahill's work by many years, and people literally didn't know how to use MVCC to provide SSI at the time.

Postgres will not necessarily do a full external merge sort for the query plan shown in the article: when there is a LIMIT k clause, the Postgres sorting code has optimizations to only keep the top k values in memory and do an in-memory sort (obviously, a full seqscan of the input is still needed without an index). Search for TSS_BOUNDED and tuplesort_set_bound() here:

https://github.com/postgres/postgres/blob/master/src/backend...

SSDs are much more complicated than spinning disks, so if anything the problem has gotten worse.

Japan's is only slightly higher, at 35.64%:

http://www.kpmg.com/global/en/services/tax/tax-tools-and-res...

but that will actually be cut below 30% in the near future:

http://money.cnn.com/2014/06/24/news/economy/japan-abenomics...

http://www.pgcon.org/2014/schedule/events/661.en.html

I don't think that's true; moreover, it is likely to become even less true in the future. Once the data needed for a computation has arrived at the CPU, for most applications the required computation is pretty cheap -- the time spent waiting for the data often dominates the time spent computing with the data. Much of modern CPU design has been devoted to trying to hide the high latency of memory accesses.

http://www.cis.gvsu.edu/~kurmasz/Teaching/OldCourses/CS451/G...

It is not "semantically wrong": conceptually, you can compute a join by taking the Cartesian product and then applying the join predicates to the result, which is actually what the implicit join syntax suggests. Semantically, there is no difference between applying an (inner) join predicate and applying any other predicate. There is also no actual division between "building the set" and "filtering the result": different predicates might be applied in different orders, before or after different relations in the query have been accessed.

The same is true of the Internet in general.

I wouldn't be so sure that 23andMe's business model depends on their customers being uninformed -- for $99, you don't need a vast amount of actionable investment to justify the purchase. Hell, getting your teeth cleaned without insurance can easily cost you more than $100. I wasn't expecting a ton of actionable insight from 23andme, but I don't regret spending the $99.