HN user
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.
OrientDB is a good open-source database that exposes a primarily object data model (the document and graph abstractions are built on top of it).
Lack of a good query language and scalability issues doomed those. Mike Stonebraker (https://blog.grakn.ai/what-goes-around-comes-around-52d38ee1...) had a nice summary in that article.
Regarding 2: note that this is not the Cambridge Analytica data, rather similar data collected by researchers at Cambridge.
Regarding (1), they could just lease the cars from the car manufacturers. As I recall, that was one of the reasons why GE invested so heavily in Lyft.
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.
Actually the queens problem starting with an empty board is not NP-Hard. See: https://cstheory.stackexchange.com/questions/12682/is-the-n-...
The "completion" problem is the NP-Hard one. As one of the other comments noted, the paper behind this press release is about the completion problem.
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.
The parallelization problem doesn't really go away though, since you still need to figure out how to do that to exploit all the cores effectively.
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:
http://dl.acm.org/citation.cfm?id=1687730
This one appears to be a more recent survey paper by some of those authors:
http://www.morganclaypool.com/doi/abs/10.2200/S00514ED1V01Y2...
As someone else pointed out, this was also one of Netezza's differentiation.
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).
I think the following is a better references for putting unstructured property graphs or RDF into relational schemas.
SQLGraph: An Efficient Relational-Based Property Graph Store; SIGMOD 2015.
Previous hackernews discussion: https://news.ycombinator.com/item?id=11101013
There are several startups in that space, e.g., Domino Data Labs, that have been trying to make it easy to do collaborative/versioned notebooks. I have only seen the product videos so don't know how well they work etc.
Thanks for that link. However, they appear to conclude Flink and Storm are quite similar in performance.
If you really need low latencies, it is quite likely that none of these will work for you anyway and you would have to build a specialized CEP-style system.
That paper is excellent and serves as a great intro for a graduate database course. It would be remiss not to list the main author though (Joe Hellerstein, Berkeley).
Rewrite phase is also supposed to "flatten subqueries/views" (cf. "Extensible/rule based query rewrite optimization in Starburst"; SIGMOD 92) and can be fairly complex. PostgreSQL doesn't do it to the same extent as DB2, but there is certainly some complex logic involved there.
This is an old discussion on the dev list: http://www.postgresql.org/message-id/201209191305.44674.db@k...
.. which indicates that reliance on them being optimization fences may be too ingrained to change. I had assumed that they were treated as sub-selects (given the generally advanced optimizer that PostgreSQL has), and was quite surprised to realize that they aren't. I think this is a major shortcoming of PostgreSQL, especially given the readability advantages of CTEs makes them quite attractive to use (I usually recommend heavy use of CTEs to beginning SQL-ers).
I fully agree -- people underestimate this issue. We recently had a long discussion among the CS faculty on using GradeScope (a software for grading paper exams). It looks great and I would love to use it, but the feedback was that the University would not approve of it for privacy reasons. Even using Google forms is problematic for that.
As Frank notes, this is not really surprising if you have seen the recent-ish papers on sorting. It is indeed frustrating when a paper seems to have nice ideas but does not do a good enough job at the simple baselines; and in most cases, there is no way for you to easily check your intuitions :(
I think Datomic is a very interesting project for a variety of reasons like use of Datalog, immutability etc.
This particular thing seems like a backwards step though. One of the major reasons why relational databases became so popular was that: the user didn't have to think about which predicate to put first in the where clause, or which join to do first. Query optimizers can do that much better, and there is decades of research on how to optimizer relational queries (including Datalog queries -- see Deductive Databases). It is hard for users to make such decisions, and complex queries, views, runtime parameters make it near impossible to reason about performance of different queries.
There is also TelegraphCQ, a competing project at Berkeley around the same time; TelegraphCQ was also built on top of PostgreSQL and its support for Continuous Queries seems essentially identical to Continuous Views here ("materialized views", "triggers", and "continuous queries" are all quite similar to each other in terms of the underlying technology needed). TelegraphCQ was commercialized as Truviso, bought out by CISCO a few years ago.
I haven't seen too many results that rely on SETH, so just did a bit of research. Ryan Williams (from Stanford) at least doesn't believe SETH is true -- here is a nice talk by him on SETH: http://www.imsc.res.in/~vraman/exact/ryan.pdf