From the earlier cited paper, this seems to target relatively simple proofs too (i.e., hardly what "expert mathematicians can prove"): "... a broad coverage of basic mathematical theorems on calculus and the formal proof of the Kepler conjecture."
As another comparison point, my volt does about 3.5 miles per kWh at 60-65mph on a highway and close to double that at 20-30mph in cities. And it’s not that light.
Datomic doesn't have cryptographically-guaranteed immutability -- its logical data model is immutable and so you can query the past versions of data etc., but there isn't anything stopping one from altering the history. In a ledger like this, history cannot be modified (assuming reasonable computational limits). Datomic also has much richer data model and query languages.
I don't know about Neptune -- curious to hear what it is based on -- but TitanDB never really supported cross-machine traversals for the execution engine. The data was stored in a distributed fashion (across say a Cassandra cluster), but any instance of the execution engine was single-machine, with no easy way to talk between multiple instances of the execution engine.
I don't think this is that straightforward. One of the comments on the article said it nicely: graduate students are still being trained and are not very effective researchers, and they are getting a significant education in doing research even if they are not taking classes (whether it is "valuable" or not today is a different discussion).
Already the cost for a postdoc is comparable to that of a student (including tuition) and probably about twice that of a student excluding tuition, and their research output can easily be more than twice that of a student (on average). There could be adjustments to the model, but charging tuition to the students is not that outrageous when you consider what the students are learning. Tuition is also typically charged on the standard credit rate for classes (pretty low for public universities).
There is lot of somewhat-researchy work on this topic, the primary one being the effort at Microsoft Research, called AutoAdmin, that started about 20 years ago. They looked at automatically creating indexes, views, histograms, and stuff like that. Peloton@CMU is a more recent incarnation of the same idea with newer tradeoffs.
Although it might sound easy, this turns out to be a very challenging problem for many technical reasons.
A primary reason for it not getting traction in practice is also that, database administrators don't like an automated tool messing with their setup and potentially nullifying all the tricks they might have played to improve the performance. This was especially true in big DB2/Oracle deployments, but is increasingly less true, which has opened it up for innovations in the last few years.
Yes, I was just reading through that. The server is still single-threaded though -- they are getting the parallelism by starting multiple processes to do independent chunks of work. This makes sense for PostgreSQL, but has some fundamental limitations (e.g., it requires duplicated copies of a hash table to parallelize a hash join).
Aside from tooling, those systems often perform much better than PostgreSQL for large queries or transactions, as they feature much better optimizations. Even outside of newer optimizations like "columnar" storage, several of those systems do code generation from queries to avoid function calls, branches, etc., which can have huge performance implications. I worked on the internals of PostgreSQL once, and the number of function calls in the innermost loops were very high.
PostgreSQL also used to be (is?) single-threaded, which limited performance of a single query on multi-core machines -- I haven't looked into it to see if there has been any fundamental change in the architecture in the last 4-5 years.
The million-dollar prize just appears to be the Clay Institute's prize for solving P vs NP. I am guessing that the queens problem (a special case of maximum independent set in a graph) is NP-Hard.
This appears to be a paper written for satisfying a CS Master's degree requirement. If you are looking for a survey on this topic, this is probably a better starting point: https://arxiv.org/abs/1504.00616
This is in line with the tenure cases that I have seen (across US) -- the department votes tend to be in early Fall, and the case makes its way through the rest of the univ over the next 5-6 months.
It's not very efficient if you have a large number of triggers. There was an early research prototype called Triggerman (http://ieeexplore.ieee.org/document/754942/) which attempted to scale triggers, but most implementations are still clunky (probably because of the transactional guarantees required by triggers).
Materialized views (that the article talks about) is a related concept, but only a few databases really support that.
Both of these are also related to the work on 'Stream Databases', where the problems of efficient recomputation are central. There is a ton of work on this in academic research (http://www.springer.com/gp/book/9783540286073), but it hasn't been able to gain a foothold in the data management market (several of the academic research projects transitioned into startups).
There is quite a bit of work on this topic in Databases, and stream processing is one of the primary use cases they identified (in particular, if you can put the FPGA device between the network and the CPU, it works out quite well). This is one of the early papers:
This (CMU Course) is a graduate research-oriented course, with lots of research papers as required reading.
6.830 is a standard introductory database course (although somewhat more advanced than other introductory database courses like Stanford CS245, or Berkeley CS186).